doxygen-users — List for users of doxygen

RE: [Doxygen-users] java documentation

[Stephen Morrison<mor...@no...>]

I've seen this problem too.  It also happens when a class extends another
class.

-----Original Message-----
From: Benoit Cerrina [mailto:b.c...@wa...]
Sent: Wednesday, April 03, 2002 5:42 PM
To: Doxygen Users List
Subject: [Doxygen-users] java documentation


Hi,
I haven't tried 1.2.15 yet but it seems that with 1.2.14-20020324 there is a
problem
with the generated java documentation.
test.zip is a sample file tree which presents the problem.
The problem is that when a class implements an interface which is from a
different package the class does not appear to inherit from it.
The incorrectly documented class is java3.
Benoit

Re: [Doxygen-users] SOURCE_BROWSER and h-files

[Dimitri v. H. <di...@st...>]

On Wed, Apr 03, 2002 at 05:06:44PM +0200, Alexander Zimmermann wrote:
> Hello,
> 
> I want doxygen to not include any soure in the generated HTML
> documentation. But when I set
> SOURCE_BROWSER = NO
> only the sources of my c-files are not generated, but the sources of the
> h-files still are in the documentation.
> 
> How can I make doxygen to not include any source in the documentation?
> Why are c- and h-files treated different here?
> Is this a bug or a feature?

It's a feature ;-) Set VERBATIM_HEADERS to NO to get rid of all sources.

Regards,
  Dimitri

[Doxygen-users] SGI IRIX can't compile scanner.cpp

[Bob L. <li...@lu...>]

I'm trying to compile 1.2.15 on an SGI Irix with g++,
using the irix-g++ configuration.  When it gets to
src/scanner.cpp (generated from flex), the object file
is too big and the compile ends with the message
"Error: Branch out of range"

I've tried various options, starting with -Os, but
nothing seems to help anymore (1.2.14 still worked
with -Os).  I have no other C++ compiler on this machine.
Any suggestions?

-- 
Bob Lied

RE: [Doxygen-users] Lists inside parameter definitions.

[Darren B. <db...@ga...>]

I had a similar issue, trying to list fields within a structure that should
be set.  The @arg directive makes a bulleted list within the right hand side
of the parameter table.  The @p just puts the field name in fixed pitch.
You would generate a similar table, with enumerated values.

    @param   pTaskDescr   @arg @p ->name Name of task to create
                          @arg @p ->sStkSize Size of supervisor 
                                             stack to allocate.
                          @arg @p ->uStkSize Size of user stack to allocate.
                          @arg @p ->priority Priority at which task will
run.
    @param   somethingElse The next parameter

The only quibble I see is that my HTML has an extra line of white space
within the parameter table.  The RTF output didn't.


-----Original Message-----
From: Putman, Harold [mailto:Pu...@di...]
Sent: Wednesday, April 03, 2002 8:14 AM
To: 'dox...@li...'
Subject: [Doxygen-users] Lists inside parameter definitions.


Is there a way to insert a list of possible parameter values inside a @param
tag. For example

/**
* A function
* @param code the operation code
*   - copy 
*   - cut
*   - paste
* @param data the data to operate on
*/
void MyFunction(int code, void* data)
  {
  }

This generates two Parameters: sections in the documentation for the
function rather than embedding the list in the definition of the first
parameter. It is not unreadable that way, I just wonder if there is a little
cleaner way to do it?

Harold Putman
H.p...@ie...

_______________________________________________
Doxygen-users mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-users

[Doxygen-users] Lists inside parameter definitions.

[Putman, H. <Pu...@di...>]

Is there a way to insert a list of possible parameter values inside a @param
tag. For example

/**
* A function
* @param code the operation code
*   - copy 
*   - cut
*   - paste
* @param data the data to operate on
*/
void MyFunction(int code, void* data)
  {
  }

This generates two Parameters: sections in the documentation for the
function rather than embedding the list in the definition of the first
parameter. It is not unreadable that way, I just wonder if there is a little
cleaner way to do it?

Harold Putman
H.p...@ie...

[Doxygen-users] SOURCE_BROWSER and h-files

[Alexander Z. <ma...@al...>]

Hello,

I want doxygen to not include any soure in the generated HTML
documentation. But when I set
SOURCE_BROWSER = NO
only the sources of my c-files are not generated, but the sources of the
h-files still are in the documentation.

How can I make doxygen to not include any source in the documentation?
Why are c- and h-files treated different here?
Is this a bug or a feature?

Bye
-- 
ma...@al...

"They that would give up essential liberty for a little
  temporary safety deserve neither liberty nor safety."
Benjamin Franklin, Historical Review of Pennsylvania, 1759

[Doxygen-users] java documentation

[Benoit C. <b.c...@wa...>]

Hi,
I haven't tried 1.2.15 yet but it seems that with 1.2.14-20020324 there is a
problem
with the generated java documentation.
test.zip is a sample file tree which presents the problem.
The problem is that when a class implements an interface which is from a
different package the class does not appear to inherit from it.
The incorrectly documented class is java3.
Benoit

[Doxygen-users] Doxygen-1.2.15 in CVS

[Olaf B. <ola...@sk...>]

Tests indicate that the blue screen is related to the DOT files.
=20
I don't know about the internals of Doxygen, so I just speculate here:
=20
Ik get a strong impression that we have a "current directory" problem.=20
Visual Studio tends to change the "current directory" during building =
and working, and this might confuse DOT if the filename passed on to DOT =
command does not contain a full path, but relative one. Thus DOT might =
crash if it does not find the file or use an incorrect file.=20
=20
I have noticed that previous releases tends to give DOT an access =
violation at regular times. So I upgraded to the latest version which =
might give a blue screen instead of access violation.
=20
I might be totally wrong, but this might point to a correct direction. =
:-)
=20
=20
=20
=20
=20
=20
=20

RE: [Doxygen-users] Can doxygen output DocBook SGML file?

[Prikryl,Petr <PRI...@sk...>]

DocBook SGML is said to be more matured these days, but
DocBook XML is said to be the future of DocBook.  DocBook
produces now XML output -- not the DocBook.  As any well
formed XML it can be processed by XSLT tools.  It's likely that
DocBook XML will be produced this way one day ;-)

Petr

> -----Original Message-----
> From:	riso [SMTP:ri...@so...]
> Sent:	Tuesday, April 02, 2002 1:17 PM
> To:	dox...@li...
> Subject:	[Doxygen-users] Can doxygen output DocBook SGML file?
>=20
[unreadable for =
me]=8Cr=81=E9=EE=B1=EA=EC=99=A8=A5=8Ax%=8A=CBC=A3=1C=A0z{=ACz=BB%=8A=CBl=
=B2=8B=ABq=E7=E8=AE=07=A7z=D8m=B6=9B?=FEX=AC=B6=CB(=BA=B7=1E~=8A=E0
zw=AD=FEX=AC=B6=CF=E5=8A=CBb=9D=FA?v=8Cr=81=E9=EE=B1=EA=EC

[Doxygen-users] Inheritance Diagrams for Java

[Stephen Morrison<mor...@no...>]

Hi,

I was wondering if anyone had noticed that inheritance diagrams seem to be a
bit broken in 1.2.15 (at least for Java)?  For example, I have a common
"Application" class that a lot of classes in the source tree extend from
(i.e. Public Class Foo extends Application). Classes that extend Application
no longer show up in Application's inheritance diagram. The only things that
appear are classes in packages that are subpackages of the package in which
Application (com.our.package.app) is contained. i.e.
com.our.package.app.testharness. I've noticed this is happening with other
"common" classes that are extended by classes as well.

It didn't used to be like this, I used to see a nice big gif with all these
many classes hanging off the back of Application. Did something change in
the way inheritance is calculated?

Cheers

Stephen

[Doxygen-users] Doxygen-1.2.15 in CVS

[Dimitri v. H. <di...@st...>]

Hi,

This mail is just to announce that version 1.2.15 of doxygen is now in CVS. 
There is not too much changed since last week's release, mainly 
some restructuring & additions to the XML parser related code.

Regards,
  Dimitri

[Doxygen-users] Can doxygen output DocBook SGML file?

[riso <ri...@so...>]

Re: [Doxygen-users] Doxygen-1.2.14-20020324 in CVS

[Benoit C. <b.c...@wa...>]

Thanks for the improved java support. I'm trying it as I write.
Benoit
----- Original Message -----
From: "Dimitri van Heesch" <di...@st...>
To: <dox...@li...>
Sent: Sunday, March 24, 2002 9:14 PM
Subject: [Doxygen-users] Doxygen-1.2.14-20020324 in CVS


> Hi,
>
> This week's changelog looks as follows:
> --------------------------------------------------------------------------
----
> + BUG: The argument of commands like \c did not produce a link to
>        external documentation if possible, while links to local
>        documentation were generated.
> + ADD: Improved support for Java. Packages are now treated like
>        C++ namespaces and there is a new option OPTIMIZE_OUTPUT_JAVA
>        that, when enabled, provides more Java-oriented output. Please
>        report any Java-related problems that remain.
> + BUG: Improved source cross referencing for members inside
>        (nested) classes/namespaces.
> + ADD: Made inheritance/collaboration diagrams accessible via the
>        XML parser API (see addon/doxmlparser/include/doxmlintf.h).
> --------------------------------------------------------------------------
----
> Enjoy,
>   Dimitri
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] alias example in manual does not work properly

[Dimitri v. H. <di...@st...>]

On Wed, Mar 27, 2002 at 03:03:15PM -0500, Phil Edwards wrote:
> On Wed, Mar 27, 2002 at 09:02:42AM +0100, Alexander Lichius wrote:
> > I found that "bug" too but didn't realized that it is a bug. I tried to
> > define some aliases to include the CVS header verbatim
> > <br>style. So I added the alias section:
> > <br>&nbsp;&nbsp;&nbsp; ALIASES = "cvsid=@version @verbatim" \
> > bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> > "endcvsid= @endverbatim"
> > <br>to my doxygen config file. It just behaves like Phil described: the
> > whole documentation block is removed from the generated
> > <br>documentation. When I replace the two commands with the plain verbatim/endverbatim
> > commands everything works fine.

Alexander: please don't send HTML to the mailing list!

> 
> I've gone through and replaced all the the aliases with plain if/endif
> commands, and things are working better.  (Not perfetly, but better.)
> Either the alising code needs to be redone, or the example in the manual
> should be removed.
> 
> It appears (this is only a guess) that the alias replacements are done
> late in the processing.  We just experimented with an alias like
> 
>     "foo=This is some very common text."
> 
> But then the @foo in the documentation blocks goes unnoticed, and the output
> contains an actual "@foo".  Perhaps this is beyond what the aliases were
> originally intended for, since there is no actual Doxygen @ command in
> the replacement text.  Bummer, that could have saved us a lot of typing.  :-)

Please report such behaviour as a bug report to me (or the bug tracker
at sourceforge) and include a real source fragment and the config file.
Don't forget to mention the version of doxygen and the platform you 
are using.

> 
> I briefly looked at the source for 1.2.14, to try and move alias expansion
> earlier in the processing, but couldn't find where to make such a change.

The substitutions are done in the source parsing phase (look for aliasDict in
scanner.l). This should be early enough I suppose.

Regards,
  Dimitri

RE: [Doxygen-users] Doxygen Source Documentation Problems

[Scot W. <sc...@wi...>]

> I think its valid to state that doxygen is for documenting interfaces
> and not implementations. And that it can be used for programs although its
> benefit is realized better with libraries.

Yup, the Doxygen documentation does state that it's for documenting 
interfaces.  Obviously a lot of users are also writing application programs, 
and Doxygen is quite close to what's needed.  I think it's the best public tool 
which runs on many platforms, at least for a few more months when a software 
understanding project is scheduled for public release.  There are tools which 
are better for a few platforms or a few environments, but they're not as 
generalized as Doxygen.

> And try not to expect so much from one tool if your not willin' to get
> your hands a little dirty, either by abusing it or by aiding in the
> development.

Oh, I've gotten dirty up to my elbows.  You just can't tell because I had to 
wash it off.  The source code page generator understands source code (code.l) 
well enough that it almost can emit enough flow information (FLOWKW) for a 
flowchart or function call (FuncCall) crossreference.  The Doxygen comment 
scanner (scanner.l) understands declarations but not flow control, and I did 
not successfully interface the two.

[Doxygen-users] Wow :-)

[Berno L. <ber...@ep...>]

Hi Dimitri,

I just want to say a big Tank You for implementing the package namespace =
in=20
Doxygen. I didn't took a deeper look on it until now, but all the=20
"TestAll"-Classes of my packages appeared in the docu :-)

---
Gru=DF

Berno

Re: [Doxygen-users] alias example in manual does not work properly

[Phil E. <ph...@ja...>]

On Wed, Mar 27, 2002 at 09:02:42AM +0100, Alexander Lichius wrote:
> I found that "bug" too but didn't realized that it is a bug. I tried to
> define some aliases to include the CVS header verbatim
> <br>style. So I added the alias section:
> <br>&nbsp;&nbsp;&nbsp; ALIASES = "cvsid=@version @verbatim" \
> bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> "endcvsid= @endverbatim"
> <br>to my doxygen config file. It just behaves like Phil described: the
> whole documentation block is removed from the generated
> <br>documentation. When I replace the two commands with the plain verbatim/endverbatim
> commands everything works fine.

I've gone through and replaced all the the aliases with plain if/endif
commands, and things are working better.  (Not perfetly, but better.)
Either the alising code needs to be redone, or the example in the manual
should be removed.

It appears (this is only a guess) that the alias replacements are done
late in the processing.  We just experimented with an alias like

    "foo=This is some very common text."

But then the @foo in the documentation blocks goes unnoticed, and the output
contains an actual "@foo".  Perhaps this is beyond what the aliases were
originally intended for, since there is no actual Doxygen @ command in
the replacement text.  Bummer, that could have saved us a lot of typing.  :-)

I briefly looked at the source for 1.2.14, to try and move alias expansion
earlier in the processing, but couldn't find where to make such a change.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

[Doxygen-users] Bug? Namespace aliases

[Howard K. <hka...@ma...>]

[Accidentally posted earlier to the wrong list; sorry if this is redundant
for some of you.]

Are there problems with namespace aliases?


I have 2 libraries.

One is equivalent to the Microsoft Platform SDK -- I just use it.
It has a header file (BCC.HPP)
	/**
	 * @namespace BigComputerCorporation
	 * The big namespace blah blah blah 
	 */
	namespace BigComputerCorporation
	{
	...
	}
	/** 
	 * @namespace BCC
	 * Alias for BigComputerCorporation
	 */
	namespace BCC = BigComputerCorporation;
with some files like
	/**
	 * ...doxygen documentation...
	 */
	void BCC::SomeClass::SomeMethod() { ... }
and it has doxygen generated docs.

In my library, I have a header (REMORA.HPP)
	#include <BCC.HPP>
	namespace BigComputerCorporation
	{
	/**
	 * @namespace Remora
	 * A small addition blah blah blah
	 */
	namespace Remora
	{
	/**
	 * Nifty extension blah blah blah
	 */
	class NiftyExtension
	{
		public: static void blah();
	};
	}
	}
and a source file (REMORA.CPP)
	#include <REMORA.HPP>
	/**
	 * My docs that doxygen doesn't include in its output!
	 */
	void BCC::Remora::NiftyExtension::blah() { do_something_cool(); }


When I run Doxygen I see it preprocesses REMORA.HPP and REMORA.CPP, but the
generated docs only have the raw signatures -- blah()'s documentation is
*not* included in the output.

Doxygen also spews a warning message for blah() (and anything else specified
with the BCC namespace alias).


If I add to REMORA.HPP the snippet
	#if defined(DOXYGEN_SHOULD_SKIP_THIS)
	namespace BCC = BigComputerCorporation;
	#endif
then suddenly doxygen generates output with all my doccomments for blah()
and the like.


Why?

The "BCC" namespace alias statements seems to be handled properly if it's in
a file specified in the INPUT/FILE_PATTERNS tag, but if it's just #include'd
by one of the INPUT files then doxygen seems to ignore it (causing
downstream havoc).


Smells like a bug to me.

I've added the hackaround for now, but it seems pretty ugly -- especially as
we plan to break up some monolithic applications into collections of smaller
toolkits/SDKs, and we have some namespace aliases (everything's scoped to a
COMPANY::PROJECT namespace, and we use namespace aliases wherever we can as
the COMPANY and PROJECT names can be annoyingly long; namespace aliases to
the rescue! But doxygen doesn't seem to play nice with the other
children...).

	- Howard

[Doxygen-users] SGI IRIX problems (tar attachment)

[Henrik P. <hen...@Un...>]

Sorry for the virus warnings - I tar/gzip'ed the diff files.

-- Henrik.

-------

Dipl.-Inform. Henrik Putzer

Universit=E4t der Bundeswehr M=FCnchen		Tel.: +49-(0)89-6004-3579
Werner-Heisenberg-Weg 39			Fax: +49-(0)89-6004-2082
85579 Neubiberg

[Doxygen-users] Email Rejected: Unknown or disallowed attachment type

[<ro...@vo...>]

Received: from [198.76.25.3] (HELO nns.voyanttech.com)
  by voyanttech.com (CommuniGate Pro SMTP 3.4b3)
  with SMTP id 2066323 for gle...@vo...; Wed, 27 Mar 2002 02:10:16 -0700
Received: from usw-sf-list1.sourceforge.net (usw-sf-fw2.sourceforge.net [216.136.171.252])
	by nns.voyanttech.com (8.9.3+Sun/8.9.3) with SMTP id DAA23746
	for <gle...@vo...>; Wed, 27 Mar 2002 03:08:04 -0500 (EST)
Received: from localhost ([127.0.0.1] helo=usw-sf-list1.sourceforge.net)
	by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian))
	id 16q9OY-0006H2-00; Wed, 27 Mar 2002 01:07:02 -0800
Received: from gatesrv.rz.unibw-muenchen.de ([137.193.11.27])
	by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian))
	id 16q9Nx-0006Cr-00
	for <dox...@li...>; Wed, 27 Mar 2002 01:06:25 -0800
Received: from kommsrv.RZ.UniBw-Muenchen.de (kommsrv [137.193.10.8])
	by gatesrv.RZ.UniBw-Muenchen.de (8.11.2/8.11.2) with ESMTP id g2R95bK06977
	for <dox...@li...>; Wed, 27 Mar 2002 10:05:37 +0100 (MET)
Received: from ikus (Ikus.LRT.UniBw-Muenchen.de [137.193.249.230])
	by kommsrv.RZ.UniBw-Muenchen.de (8.12.1/8.12.1) with SMTP id g2R95aPA011654
	for <dox...@li...>; Wed, 27 Mar 2002 10:05:36 +0100 (MET)
X-Envelope-Sender: hen...@un... as seen by kommsrv.RZ.UniBw-Muenchen.de
From: "Henrik Putzer" <hen...@Un...>
To: <dox...@li...>
Message-ID: <DHE...@un...>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0000_01C1D577.446D41C0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <200...@di...n>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: [Doxygen-users] [Doxygen] SGI IRIX problems
Sender: dox...@li...
Errors-To: dox...@li...
X-BeenThere: dox...@li...
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:dox...@li...?subject=help>
List-Post: <mailto:dox...@li...>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/doxygen-users>,
	<mailto:dox...@li...?subject=subscribe>
List-Id: <doxygen-users.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/doxygen-users>,
	<mailto:dox...@li...?subject=unsubscribe>
List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=doxygen-users>
X-Original-Date: Wed, 27 Mar 2002 10:07:56 +0100
Date: Wed, 27 Mar 2002 10:07:56 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C1D577.446D41C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


Hi Dimitri, hi all -

I compiled DOXYGEN-1.2.14 on my IRIX 6.5 box (native CC compiler) and had to
make the following changes to the code located in doxygen-1.2.14/src

1) changed 'dot.cpp' (see attachment dot.cpp.diff)
2) changed 'memberdef.cpp' (see attachment memberdef.cpp.diff)
3) 'translator_fr.h' and 'translator_pt.h' have DOS-like linebreaks - this
can not be processed so I had to run a to_unix (on Linux: dos2unix ?!) on
them

to 1) and 2)
The code in these files contain typecasts from pointer to int - this is no
good practice - I'm not sure, if I did it right, but as a quick hack, I
provided a union for the conversion like
union _castPtr {
  void* ptr;
  int i;
};
... assigned the pointer to 'ptr' and used the integer 'i' - this compiles
and the doxygen output looks ok (but my compound list is empty - not sure,
if it should be).

Thanks for the great tool,
-- Henrik

-------

Dipl.-Inform. Henrik Putzer

Universitat der Bundeswehr Munchen		Tel.: +49-(0)89-6004-3579
Werner-Heisenberg-Weg 39			Fax: +49-(0)89-6004-2082
85579 Neubiberg


------=_NextPart_000_0000_01C1D577.446D41C0
Content-Type: application/octet-stream;
	name="dot.cpp.diff"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;

FOR ANTI-VIRUS SECURITY, THIS EMAIL HAS BEEN CLEANED.

REASON:
THIS EMAIL CONTAINED AN ATTACHMENT TYPE OF '.diff' WHICH IS NOT PERMITTED.

[Doxygen-users] [Doxygen] SGI IRIX problems

[Henrik P. <hen...@Un...>]

Hi Dimitri, hi all -

I compiled DOXYGEN-1.2.14 on my IRIX 6.5 box (native CC compiler) and had to
make the following changes to the code located in doxygen-1.2.14/src

1) changed 'dot.cpp' (see attachment dot.cpp.diff)
2) changed 'memberdef.cpp' (see attachment memberdef.cpp.diff)
3) 'translator_fr.h' and 'translator_pt.h' have DOS-like linebreaks - this
can not be processed so I had to run a to_unix (on Linux: dos2unix ?!) on
them

to 1) and 2)
The code in these files contain typecasts from pointer to int - this is no
good practice - I'm not sure, if I did it right, but as a quick hack, I
provided a union for the conversion like
union _castPtr {
  void* ptr;
  int i;
};
... assigned the pointer to 'ptr' and used the integer 'i' - this compiles
and the doxygen output looks ok (but my compound list is empty - not sure,
if it should be).

Thanks for the great tool,
-- Henrik

-------

Dipl.-Inform. Henrik Putzer

Universitat der Bundeswehr Munchen		Tel.: +49-(0)89-6004-3579
Werner-Heisenberg-Weg 39			Fax: +49-(0)89-6004-2082
85579 Neubiberg

Re: [Doxygen-users] alias example in manual does not work properly

[Alexander L. <li...@we...>]

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I found that "bug" too but didn't realized that it is a bug. I tried to
define some aliases to include the CVS header verbatim
<br>style. So I added the alias section:
<br>&nbsp;&nbsp;&nbsp; ALIASES = "cvsid=@version @verbatim" \
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"endcvsid= @endverbatim"
<br>to my doxygen config file. It just behaves like Phil described: the
whole documentation block is removed from the generated
<br>documentation. When I replace the two commands with the plain verbatim/endverbatim
commands everything works fine.
<p>Alex
<p>Phil Edwards schrieb:
<blockquote TYPE=CITE>The manual for 1.2.14 shows an example for the \if
command in section 22.37.&nbsp; It involves an alias section like
<p>&nbsp;&nbsp;&nbsp; ALIASES = "english=\if english" \
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"endenglish=\endif" \
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"dutch=\if dutch" \
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"enddutch=\endif"
<p>and then the conditional blocks are written
<p>&nbsp;&nbsp;&nbsp; \english
<br>&nbsp;&nbsp;&nbsp; ....
<br>&nbsp;&nbsp;&nbsp; \endenglish
<p>We're using this exact same technique, but we get a warning,
<p>&nbsp; 1556: Documentation block ended in the middle of a conditional
section!
<p>The line number is in the middle of a block of code, and the entire
<br>documentation block is not emitted.&nbsp; (I think this may actually
be the
<br>cause of the conditional documentation bug I reported earlier.)
<p>Replacing the aliased \if and \endif commands with regular \if and \endif
<br>causes the warning to stop and the conditional sections to work properly.
<br>I haven't tested this with the code being used in the previous bug
report (it
<br>takes about ten minutes for a doxygen run, so I can't spend all day
on it),
<br>but if this works around the bug, then we'll just have to give up on
using
<br>aliases for conditional blocks.
<p>Phil
<p>--
<br>If ye love wealth greater than liberty, the tranquility of servitude
greater
<br>than the animating contest for freedom, go home and leave us in peace.&nbsp;
We seek
<br>not your counsel, nor your arms.&nbsp; Crouch down and lick the hand
that feeds you;
<br>and may posterity forget that ye were our countrymen.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- Samuel Adams
<p>_______________________________________________
<br>Doxygen-users mailing list
<br>Dox...@li...
<br><a href="https://lists.sourceforge.net/lists/listinfo/doxygen-users">https://lists.sourceforge.net/lists/listinfo/doxygen-users</a></blockquote>

<pre>--&nbsp;
Alexander Lichius
Diplom-Ingenieur
Communication and Information Systems
Werum Software &amp; Systems AG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Wulf-Werum-Strasse 3 | D-21337 Lueneburg
Tel. +49 4131 8900-623 | Fax +49 4131 8900-20&nbsp;
<A HREF="mailto:li...@we...">mailto:li...@we...</A> | <A HREF="http://www.werum.de">http://www.werum.de</A></pre>
&nbsp;</html>

[Doxygen-users] alias example in manual does not work properly

[Phil E. <ph...@ja...>]

The manual for 1.2.14 shows an example for the \if command in section 22.37.  It involves an alias section like

    ALIASES = "english=\if english" \
              "endenglish=\endif" \
              "dutch=\if dutch" \
              "enddutch=\endif"

and then the conditional blocks are written

    \english
    ....
    \endenglish

We're using this exact same technique, but we get a warning,

  1556: Documentation block ended in the middle of a conditional section!

The line number is in the middle of a block of code, and the entire
documentation block is not emitted.  (I think this may actually be the
cause of the conditional documentation bug I reported earlier.)

Replacing the aliased \if and \endif commands with regular \if and \endif
causes the warning to stop and the conditional sections to work properly.
I haven't tested this with the code being used in the previous bug report (it
takes about ten minutes for a doxygen run, so I can't spend all day on it),
but if this works around the bug, then we'll just have to give up on using
aliases for conditional blocks.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

[Doxygen-users] conditional sections broken after 1.2.12

[Phil E. <ph...@ja...>]

I have some doc blocks that look like this:
 
     /**
      *   Some general information.
      *
      *   @if maint
      *   Maintainer information.
      *   @endif
     */
     the entity (class, whatever) to be documented ....
 
This worked fine up until recently.  Now the conditionals are taking
over the entire documentation block!  If 'maint' is enabled everything
appears, but if 'maint' is not enabled, then /nothing/ appears, not even
the general information.  The entire class is considered undocumented by
doxygen, and no output is produced at all.

Versions prior to 1.2.12 did not have this bug.  I have just tried it
again with 1.2.14 and the bug is still present.

I reported it on the mailing list with 1.2.12 but got no response.
I submitted a bug to the sourceforge bug tracker but got no response
(see URL).  Am I the only one who uses documentation blocks containing
partial conditional sections?

http://sourceforge.net/tracker/?func=detail&atid=105971&aid=514663&group_id=5971


Thanks for /any/ reply,
Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

RE: [Doxygen-users] Doxygen Source Documentation Problems

[DevHed <de...@du...>]

I think its valid to state that doxygen is for documenting interfaces and
not implementations. And that it can be used for programs although its
benefit is realized better with libraries.

I, for one, think that any ongoing maintenance of any software would benefit
from this including doxygen, but keep it to the interfaces. Look at the code
if you need to understand the implementation. Hopefully there's a few native
comments in there to help you along.

And try not to expect so much from one tool if your not willin' to get your
hands a little dirty, either by abusing it or by aiding in the development.

Dev

> -----Original Message-----
> From: dox...@li...
> [mailto:dox...@li...]On Behalf Of Scot
> Wilcoxon
> Sent: Monday, March 25, 2002 3:15 PM
> To: dox...@li...
> Subject: Re: [Doxygen-users] Doxygen Source Documentation Problems
>
>
> > I'm trying to build the documentation to doxygen, I noticed it's not
> > built into the source code, I can't imagine why, the source
> DEFINIETLY needs
> > documenting, external documentation like this just isnt enough I find,
> > but anyway.
>
> Doxygen is for documenting variables and functions, not programs.
> Doxygen is a program.
>
> You'll first need to expand Doxygen as previously mentioned to
> support things
> such as program flow documentation.  ("This is an IF statement.
> See the IF
> statement run over here when the array gets too full.  Run, IF, Run!")
>
> Well, the source code HTML creator does understand some language
> keywords and
> puts "IF" in a pretty color, but there's no way to attach
> documentation to
> code, only to declarations.
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>