doxygen-users — List for users of doxygen

RE: [Doxygen-users] Documenting #included files

[Trevor R. <Tre...@pe...>]

Jac,

Thanks for your reply.  If your {} trick works, it might be helpful,
although I'd rather not split the class tag from the guts of the class.

The main problem with your macro-hack variation is that I can't include
inline documentation for the class.  I'd have to use \fn style of
documentation, which I find unacceptably hard to maintain due to the
redundancy.  (In addition to my abstract buffer class, I have 3 derived
classes that need to use the same template emulation.)  A couple more
reasons: 1) It's no fun to remember to put backslashes at the end of every
line.  2) The entire class is now a big text blob that editors and other
tools don't understand, so they won't do things like syntax highlight, match
parentheses, or auto-generate doc comments.  3) I might eventually hit some
sort of maximum macro length in one of the six preprocessors I'm using.  (We
use 5 compilers on 4 platforms, plus an additional make-dependency
preprocessor on Windows since VC++ doesn't generate make dependencies.)

Anyway, it sounds like you agree on the usefulness of telling Doxygen to
document #included files.  Do you have any proposed syntax?  If you don't
have time to finish your patch for this, I could do it myself.  (I had
already assumed I'd have to add it if I wanted it.)

-Trevor


-----Original Message-----
From: Jac Goudsmit [mailto:ja...@ma...]
Sent: Wednesday, May 02, 2001 4:25 PM
To: dox...@li...
Subject: Re: [Doxygen-users] Documenting #included files


>Could anyone (Dimitri?) tell me if it is possible to get Doxygen to 
document
>the contents of a file that is #included inside another file?

Currently, the only way to force include files to get documented is by 
opening them inside a curly-brace '{}' pair. My guess is that this 
should work, but I didn't actually test it:

class class1
{
#include "the_rest_of_the_class_declaration"
};

class class2
{
#include "the_rest_of_the_class_declaration"
};

I have been working on a few new doxygen commands to force it to 
preprocess include-files, but I'm so busy that the project is on hold 
for now.

By the way, if you want to macro-hack templates, why don't you try 
something like this (doxygen will understand this I think):

#define DECLARE_ARRAY_CLASS(type) \
class type##_array \
{ \
	type##_array() { ... } \
     ~type##_array() { ... } \
\
	type operator[](int index) { ... } \
	...etc... \
};

DECLARE_ARRAY_CLASS(int) // declare int_array and all its methods
DECLARE_ARRAY_CLASS(char) // declare char_array and all its methods

===Jac

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

Re: [Doxygen-users] Documenting #included files

[Jac G. <ja...@ma...>]

>Could anyone (Dimitri?) tell me if it is possible to get Doxygen to 
document
>the contents of a file that is #included inside another file?

Currently, the only way to force include files to get documented is by 
opening them inside a curly-brace '{}' pair. My guess is that this 
should work, but I didn't actually test it:

class class1
{
#include "the_rest_of_the_class_declaration"
};

class class2
{
#include "the_rest_of_the_class_declaration"
};

I have been working on a few new doxygen commands to force it to 
preprocess include-files, but I'm so busy that the project is on hold 
for now.

By the way, if you want to macro-hack templates, why don't you try 
something like this (doxygen will understand this I think):

#define DECLARE_ARRAY_CLASS(type) \
class type##_array \
{ \
	type##_array() { ... } \
     ~type##_array() { ... } \
\
	type operator[](int index) { ... } \
	...etc... \
};

DECLARE_ARRAY_CLASS(int) // declare int_array and all its methods
DECLARE_ARRAY_CLASS(char) // declare char_array and all its methods

===Jac

[Doxygen-users] Documenting #included files

[Trevor R. <Tre...@pe...>]

Hello,

Could anyone (Dimitri?) tell me if it is possible to get Doxygen to document
the contents of a file that is #included inside another file?

Specifically, I need to include a header multiple times, but with different
#defined placeholders.  Basically, I'm trying to emulate a class template
with a macro "hack" (as in the pre-template days).  I know it's evil, but
I'm writing a portability library, and many of our tools are deficient in
handling templates.  For example, Visual C++ 6 has so many caveats (some
documented, some not) on exporting template instantiations through a DLL
that it's effectively incapable of it.  Also, the Visual Studio debugger
apparently doesn't understand polymorphic templates.  (It will show you the
derived class of an object through a base class pointer for a normal class,
but not for template classes.)

Anyway, here's an example.  I want to see both CPSAbstractByteBuffer and
CPSAbstractCharBuffer documented, but not PS_ABSTRACT_T_BUFFER.

psabstractbuffer.h:

/**
 * Abstract dynamic buffer class.
 */
class PSCL_IMPEXP PS_ABSTRACT_T_BUFFER : public CPSObject
{
public:
    virtual const T* GetData() const = 0;
...
};

psbuffer.h:

#define T                               PS_BYTE
#define PS_ABSTRACT_T_BUFFER            CPSAbstractByteBuffer
#include "psabstractbuffer.h"
#undef T
#undef PS_ABSTRACT_T_BUFFER

#define T                               PS_CHAR
#define PS_ABSTRACT_T_BUFFER            CPSAbstractCharBuffer
#include "psabstractbuffer.h"
#undef T
#undef PS_ABSTRACT_T_BUFFER

If Doxygen doesn't do this now, does anyone agree that it would be nice to
have some way of doing this?  Maybe a \docinclude special command?  Not
because you want to emulate class templates necessarily, but because you
might like to make it appear that a header contains definitions that it
incidentally #includes from other files.  The end user only cares about what
header he should include to get those definitions, and should be insulated
from how the designer chooses to divide up his files.  Of course, the way
Doxygen works now is the best default.

Thanks,
Trevor

RE: [Doxygen-users] CVS snapshot of doxygen-1.2.7 and config.cpp

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

The reason is that Makefile.libdoxygen assumes the existence of config.cpp,
but the file is to be generated later via Makefile.libdoxycfg.  I have
solved the
problem by switching the order of lines 18 and 19 in
doxygen/src/Makefile.in.
Then, you have to start make from the root (to let the perl generate real
makefiles).

I have already sent this directly to Dimitri.

Petr

-- 
Petr Prikryl, SKIL, spol. s r.o., pri...@sk...

> -----Original Message-----
> From:	Walter F.J. Mueller [SMTP:W.F...@gs...]
> Sent:	Wednesday, May 02, 2001 11:06 AM
> To:	dox...@li...
> Subject:	[Doxygen-users] CVS snapshot of doxygen-1.2.7 and config.cpp
> 
> Hi,
> 
> using the newest CVS snapshot (now doxygen-1.2.7) under Linux I get after
> a 
> 
> 	./configure --prefix ...
> 	make
> 
> the error
> 
> 	gmake[1]: *** No rule to make target `config.cpp', 
> 		needed by `../objects/config.o'.  Stop.
> 
> 
> Looking into Makefile.libdoxygen I see that there is no rule
> to produce config.cpp from config.l . Doing manually a 
> 
>    lex -PconfigYY -t config.l > config.cpp  
> 
> in the src directory fixed this and I could successfully build doxygen.
> 
> I guess that there is a glitch in one files steering the Makefile
> creation.
> 
> 
> 			Cheers,	Walter
> 
> --
> Walter F.J. Mueller   Mail:  W.F...@gs...
> GSI,  Abteilung KP3   Phone: +49-6159-71-2766
> D-64291 Darmstadt     FAX:   +49-6159-71-2989
> WWW:   http://www-kp3.gsi.de/www/kp3/people/mueller.html
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> http://lists.sourceforge.net/lists/listinfo/doxygen-users

[Doxygen-users] Upgraded to 1.2.7: where are the diagrams?

[Roberto B. <ba...@cs...>]

Hi there,

I have just upgraded from 1.2.6 to 1.2.7.
A first observation is that all the diagrams have disappeared:
the caption is there, i.e., "Collaboration diagram for A:",
the graph legend is there, but the collaboration diagram
is missing (I have also checked the HTML source: it is not there).
What am I missing?
All the best,

     Roberto

-- 
Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:ba...@cs...

[Doxygen-users] CVS snapshot of doxygen-1.2.7 and config.cpp

[Walter F.J. M. <W.F...@gs...>]

Hi,

using the newest CVS snapshot (now doxygen-1.2.7) under Linux I get after a 

	./configure --prefix ...
	make

the error

	gmake[1]: *** No rule to make target `config.cpp', 
		needed by `../objects/config.o'.  Stop.


Looking into Makefile.libdoxygen I see that there is no rule
to produce config.cpp from config.l . Doing manually a 

   lex -PconfigYY -t config.l > config.cpp  

in the src directory fixed this and I could successfully build doxygen.

I guess that there is a glitch in one files steering the Makefile creation.


			Cheers,	Walter

--
Walter F.J. Mueller   Mail:  W.F...@gs...
GSI,  Abteilung KP3   Phone: +49-6159-71-2766
D-64291 Darmstadt     FAX:   +49-6159-71-2989
WWW:   http://www-kp3.gsi.de/www/kp3/people/mueller.html

[Doxygen-users] Doxygen-1.2.7 in CVS

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

Hi,

Here what has changed since last CVS update:
------------------------------------------------------------------------------
+ CHG: Changed the way the translators work internally (thanks to Petr
       Prikryl for ideas and code) and updated the documentation regarding
       language support and maintenance.
       Users of languages other than English will get a warning message if
       the translation for their language is not up to date.
+ ADD: Included language updates for Croatian and Czech.
+ ADD: Added new command \addtogroup that can be used to extend a group
       defined with \defgroup with extra members and/or documentation.
+ BUG: Email addresses in the docs starting with an "a" and put inside sharp
       brackets were not properly displayed (thanks to Abramo Bagnara for
       the fix).
+ BUG: Merged man page generator patch send by Patrick Ohly. It fixes:
       - Font changes reset the font with \fR to roman,
         which is often not correct - using \fP for the
         previous font is better.
       - The arguments of .SS and .SH were not quoted,
         which seemed to work under Linux with groff,
         but not under Solaris.
       - Using a double quotation mark within the text
         broke the quotation used in the man page markup.
         I found no way to correctly escape the double
         quotes, so I replace them with single quotes.
------------------------------------------------------------------------------
Enjoy,
  Dimitri