doxygen-users — List for users of doxygen

[Doxygen-users] [newbi question] - Stripping Doxygen comments

[Steve W. <ste...@ag...>]

Hi All,

What I have noticed, looking at various groups using Doxygen is that the
development code contains doxygen comments, but the distributed source
code does not. (E.g. Doxygen etc..).
 
What script / utility  is being used to remove the comments before 
distribution of the source code ?
 
Thanks inadvance !
 
Steve Walker.

RE: [Doxygen-users] Header files in directories

[Kris T. <kri...@cs...>]

Hi all,

I would like this as well. I don't personally like the \file dir/name.h
solution. I'm renaming my header files all the time :-).

All the best

Kris Thielemans
Imaging Research Solutions Ltd
Cyclotron Building
Hammersmith Hospital
Du Cane Road
London W12 ONN, United Kingdom

web site address:
http://www.irsl.org/~kris

> -----Original Message-----
> From: dox...@li...
> [mailto:dox...@li...]On Behalf Of Carlo
> Wood
> Sent: 22 November 2001 17:27
> To: dox...@li...
> Cc: dox...@li...
> Subject: [Doxygen-users] Header files in directories
>
>
> Hi,
>
> I am using a lot  #include <directory/headerfile.h>
> Is it possible that this will be supported in a future doxygen?
>
> I suppose the support exists of two parts:
> 1) Determining the directory part.
> 2) Using the directory part in the reference/links/filenames etc.
>
> Point one could most easily be solved by using whatever is specified
> in the \file command, for example:
>
> /** \file directory/headerfile.h
>  */
>
> should use the full "directory/headerfile.h" as name.
> A nicer/better solution would be to look at the full path name
> and the include directories - from that doxygen should be able
> to determine itself when a path is used to include something.
>
> Point 2) is easy, just include a new _<digit> for '/' and
> include that in the generated file names.  And expect the
> full "directory/headerfile.h" as references in links, thus:
>
> \ref directory/headerfile.h
> is something else as
> \ref headerfile.h
>
> Regards,
>
> --
> Carlo Wood <ca...@al...>
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>

[Doxygen-users] Header files in directories

[Carlo W. <ca...@al...>]

Hi,

I am using a lot  #include <directory/headerfile.h>
Is it possible that this will be supported in a future doxygen?

I suppose the support exists of two parts:
1) Determining the directory part.
2) Using the directory part in the reference/links/filenames etc.

Point one could most easily be solved by using whatever is specified
in the \file command, for example:

/** \file directory/headerfile.h
 */

should use the full "directory/headerfile.h" as name.
A nicer/better solution would be to look at the full path name
and the include directories - from that doxygen should be able
to determine itself when a path is used to include something.

Point 2) is easy, just include a new _<digit> for '/' and
include that in the generated file names.  And expect the
full "directory/headerfile.h" as references in links, thus:

\ref directory/headerfile.h
is something else as
\ref headerfile.h

Regards,

-- 
Carlo Wood <ca...@al...>

[Doxygen-users] BUG: Input FILE_PATTERNS fails with "c*.h" and "c*.cpp"

[Roland T. <rt...@wa...>]

         Input FILE_PATTERNS  seems to fail when a c*.h or c*.cpp pattern 
is specified.

         More info:
         Working on a big project, I try to use tags for compilation speed. 
So I made config files for subdirectories (work fine, at least for what 
matters here). But I have many .h and .cpp file in my project directory. I 
try to divide sources like this :

in A_L.cfg:
...
INPUT                  = .
FILE_PATTERNS          = a*.h a*.cpp \
                         c*.h c*.cpp \
                         b*.h b*.cpp \
                         d*.h d*.cpp \
                         e*.h e*.cpp \
                         f*.h f*.cpp \
                         g*.h g*.cpp \
                         h*.h h*.cpp \
                         i*.h i*.cpp \
                         j*.h j*.cpp \
                         k*.h k*.cpp \
                         l*.h l*.cpp
...

in M_Z.cfg

...
INPUT                  = .
FILE_PATTERNS          = m*.h m*.cpp \
                         n*.h n*.cpp \
                         o*.h o*.cpp \
                         p*.h p*.cpp \
                         q*.h q*.cpp \
                         r*.h r*.cpp \
                         s*.h s*.cpp \
                         t*.h t*.cpp \
                         u*.h u*.cpp \
                         v*.h v*.cpp \
                         w*.h w*.cpp \
                         x*.h x*.cpp \
                         y*.h y*.cpp \
                         z*.h z*.cpp
...

         Each config file is intended to produce a tag file from half the 
source files.
         When run, M_Z_cfg works fine, reading M to Z files, but A_L.cfg 
reads all .h and .cpp in the current directory. When I delete the c*.h and 
c*.cpp line, it works fine (except there is no c* file).
         As I use IGNORE_PREFIX = C in these files, same char wich fails in 
pattern, I tried (why not?) with empy IGNORE_PREFIX :same error.

         The only workaround I found is specifying ca*.h ca*.cpp cb*.h 
cb*.cpp ... to cz*.cpp in FILE_PATTERN. Simpler way needed

Thanks


Roland Touchain
rt...@wa...
  

Re: [Doxygen-users] Solaris / GCC 3.0.2 linker problem

[Carlo W. <ca...@al...>]

On Wed, Nov 21, 2001 at 11:05:20AM -0500, Dooferlad wrote:
> I had to cludge the Makefile.qtools because it didn't pick up gcc (CC was
> still in there), and the origional -xar options for AR seemed to confuse
> gcc so I left them out.
> 
> This looks like an incompatability between the crt1.o that comes with gcc
> 3.0.2 and the one that the source is expecting. Any ideas?

Did you recompile *every* library on your machine with gcc-3.0.2?
Especially C++ of course (libqt thus).  You can't mix gcc-3.x
with gcc-2.x compiled (C++) libraries.

-- 
Carlo Wood <ca...@al...>

[Doxygen-users] Links to another page, but not the top.

['Carlo W. <ca...@al...>]

Hi,

I'd like to link to some anchor that is defined on
another page, but that doesn't seem to be allowed.

In the documentation of one file I added:
\anchor preparation_step2

And in another file I would like to use:

/** \file macro_ForAllDebugChannels.h
 * Do not include this header file directly, instead include \link preparation_step2 "debug.h" \endlink.
 */

However, this results in:

/home/carlo/c++/libcw_branch-threading/src/libcwd/include/libcw/macro_ForAllDebugChannels.h:1 Warning: link to unknown entity `preparation_step2' in the documentation of this entity!

Can anyone tell me if it is doable to link to an anchor that is not on
the same page?  Or am I doing something wrong?

-- 
Carlo Wood <ca...@al...>

Re: [Doxygen-users] Making an Easy and fast readable C Library Ma nual reference.(TODO-Suggestions)

['Carlo W. <ca...@al...>]

On Wed, Nov 21, 2001 at 12:32:27PM -0500, Wagner, Victor wrote:
> I don't.  For documenting a system which hasn't yet been doxygenated, ALL of
> the included includes would disappear.
> Sorry, that isn't acceptable to ME.
> If you want to "HIDE" some file... I'd be willing to consider a
> \filebutdonotmention line which people add to files they do NOT want
> mentioned.

Sounds fine by me.  It would be very nice if it allowed me to specify
which header file should be included instead.

For example a file class_foo.h with:

/** \filehidden nothidden.h */

class foo;

Would use "#include <nothidden.h>" instead of "#include <class_foo.h>".
And class_foo.h wouldn't show up in the 'File List'.

This would solve all my problems.  Not using a \file at all isn't
good anyway I discovered now, because then certain documentation
disappears (that what would be part of the file-specific page;
not, for example, some defined \interface).

-- 
Carlo Wood <ca...@al...>

RE: [Doxygen-users] Making an Easy and fast readable C Library Ma nual reference.(TODO-Suggestions)

[Wagner, V. <VW...@se...>]

I don't.  For documenting a system which hasn't yet been doxygenated, =
ALL of
the included includes would disappear.
Sorry, that isn't acceptable to ME.
If you want to "HIDE" some file... I'd be willing to consider a
\filebutdonotmention line which people add to files they do NOT want
mentioned.

-----Original Message-----
From: Carlo Wood [mailto:ca...@al...]
Sent: Wednesday, 2001 November 21 10:35
To: Stephen Goudge
Cc: 'Toni Moreno Gim=E9nez'; dox...@li...
Subject: Re: [Doxygen-users] Making an Easy and fast readable C Library
Manual reference.(TODO-Suggestions)


On Wed, Nov 21, 2001 at 08:30:31AM -0000, Stephen Goudge wrote:
> might even _want_ to use it) and I'd feel a fool if I prevented that
> because I'd been precious about my wonderful design :-)

We're clearly not talking about the same.
I tried to clearify that in a previous post, but failed apparently.

All of my header files are user-level and all of them are needed
by the user.  All of them are documented.  But just ONE needs to
be included, because it includes all others.

The "solution" of putting them in a separate directory simply
doesn't work.  This has nothing to do with doxygen *forcing* me
to use a better design of my library; instead, doxygen is simply
failing to deal with this kind of design and it would be a whole
lot better when it was fixed to NOT speak about header files
that are in the INPUT list but do NOT contain a \file command.
Evenmore, it should never print a #include <suchafile.h> when
it can see that this file is being included by a *documented*
header file.

In other words:

header1.h  : contains a \file entry and #include <header2.h>
header2.h  : does not contain a \file entry, but does define
             a documented function.
The function of header2.h then should be documented with an
#include <header1.h>, and there should not be any mention of
header2.h anywhere.

If someone wants header2.h to be mentioned in the File List,
then they should add a \file entry.  If then still they would
like to see a #include <header1.h> then they'd add an explicit
command to header2.h to achieve that (if at all possible).

I hope you can see the logic in this.

--=20
Carlo Wood <ca...@al...>

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

[Doxygen-users] Solaris / GCC 3.0.2 linker problem

[Dooferlad <doo...@th...>]

Hi,

I am running Solaris 8 with gcc 3.0.2 and I am getting the following linker
error:

gcc -o ../lib/libqtools.a ../objects/qbuffer.o ../objects/qcollection.o 
../objects/qcstring.o ../objects/qdatastream.o ../objects/qdatetime.o 
../objects/qdir.o ../objects/qfile.o ../objects/qfileinfo.o 
../objects/qgarray.o ../objects/qgdict.o ../objects/qglist.o 
../objects/qglobal.o ../objects/qgvector.o ../objects/qiodevice.o 
../objects/qregexp.o ../objects/qstring.o ../objects/qtextstream.o 
../objects/qtextcodec.o ../objects/qstringlist.o ../objects/qxml.o 
../objects/qmap.o ../objects/qfile_unix.o ../objects/qdir_unix.o 
../objects/qfileinfo_unix.o 

Undefined                       first referenced
 symbol                             in file
 __cxa_pure_virtual                  ../objects/qcollection.o
 vtable for __cxxabiv1::__si_class_type_info../objects/qbuffer.o
 vtable for __cxxabiv1::__vmi_class_type_info../objects/qxml.o
 operator new[](unsigned)            ../objects/qcstring.o
 vtable for __cxxabiv1::__class_type_info../objects/qbuffer.o
 operator delete(void*)              ../objects/qbuffer.o
 operator new(unsigned)              ../objects/qdatastream.o
 __gxx_personality_v0                ../objects/qbuffer.o
 operator delete[](void*)            ../objects/qdir.o
 main                                
 /home/jamest/progs/lib/gcc-lib/sparc-sun-solaris2.8/3.0.2/crt1.o
 ld: fatal: Symbol referencing errors. No output written to 
 ../lib/libqtools.a
 collect2: ld returned 1 exit status
 make[2]: *** [../lib/libqtools.a] Error 1

I had to cludge the Makefile.qtools because it didn't pick up gcc (CC was
still in there), and the origional -xar options for AR seemed to confuse
gcc so I left them out.

This looks like an incompatability between the crt1.o that comes with gcc
3.0.2 and the one that the source is expecting. Any ideas?

-- 
    Dooferlad
  [ http://www.thelongslide.com ]

RE: [Doxygen-users] Bug related to grouping and namespaces.

[Dalton, B. <Bar...@ra...>]

> I found another bug by the way: the order of reading the input
> files matters for addtogroup and defgroup.  I had one single
> defgroup in one file, and used addtogroup everywhere else.
> But doxygen refused to process the defgroup because it already
> (first) saw an addtogroup.  I think that the order in which
> input files are read shouldn't matter here.

I had this problem too. I had to replace the defgroup by an addtogroup.
Barney


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
pos...@ra....

This footnote also confirms that this email message has been scanned
for the presence of computer viruses known at the time of sending.

www.radioscape.com
**********************************************************************

Re: [Doxygen-users] Making an Easy and fast readable C Library Manual reference.(TODO-Suggestions)

[Carlo W. <ca...@al...>]

On Wed, Nov 21, 2001 at 08:30:31AM -0000, Stephen Goudge wrote:
> might even _want_ to use it) and I'd feel a fool if I prevented that
> because I'd been precious about my wonderful design :-)

We're clearly not talking about the same.
I tried to clearify that in a previous post, but failed apparently.

All of my header files are user-level and all of them are needed
by the user.  All of them are documented.  But just ONE needs to
be included, because it includes all others.

The "solution" of putting them in a separate directory simply
doesn't work.  This has nothing to do with doxygen *forcing* me
to use a better design of my library; instead, doxygen is simply
failing to deal with this kind of design and it would be a whole
lot better when it was fixed to NOT speak about header files
that are in the INPUT list but do NOT contain a \file command.
Evenmore, it should never print a #include <suchafile.h> when
it can see that this file is being included by a *documented*
header file.

In other words:

header1.h  : contains a \file entry and #include <header2.h>
header2.h  : does not contain a \file entry, but does define
             a documented function.
The function of header2.h then should be documented with an
#include <header1.h>, and there should not be any mention of
header2.h anywhere.

If someone wants header2.h to be mentioned in the File List,
then they should add a \file entry.  If then still they would
like to see a #include <header1.h> then they'd add an explicit
command to header2.h to achieve that (if at all possible).

I hope you can see the logic in this.

-- 
Carlo Wood <ca...@al...>

Re: [Doxygen-users] Bug related to grouping and namespaces.

['Carlo W. <ca...@al...>]

On Wed, Nov 21, 2001 at 09:16:29AM -0000, Dalton, Barnaby wrote:
> 
> I didn't get the attachment but I think I have experienced a similar
> problem. The case I had was grouping functions defined at namespace scope
> (as opposed to member fns of a class). I found that if I did a @ingroup in
> both the header and implementation file then the function was documented
> properly.
> 
> Barney

Argh - I forgot the attachment :).
I'll attach it now.  But you're right, that solved the problem.
Nevertheless, this is a bug.  I suggest to solve it as follows:

When a function (prototype, definition and/or extern declaration)
is marked as belonging to a group, then that should take
precedence over a (previously read) definition without any
comment.

I found another bug by the way: the order of reading the input
files matters for addtogroup and defgroup.  I had one single
defgroup in one file, and used addtogroup everywhere else.
But doxygen refused to process the defgroup because it already
(first) saw an addtogroup.  I think that the order in which
input files are read shouldn't matter here.

-- 
Carlo Wood <ca...@al...>

RE: [Doxygen-users] Bug related to grouping and namespaces.

[Dalton, B. <Bar...@ra...>]

I didn't get the attachment but I think I have experienced a similar
problem. The case I had was grouping functions defined at namespace scope
(as opposed to member fns of a class). I found that if I did a @ingroup in
both the header and implementation file then the function was documented
properly.

Barney

> -----Original Message-----
> From: Carlo Wood [mailto:ca...@al...]
> Sent: 21 November 2001 12:59 AM
> To: Dimitri van Heesch
> Cc: dox...@li...
> Subject: [Doxygen-users] Bug related to grouping and namespaces.
> 
> 
> I am having problems with grouping.
> The need is to create a seperate page for certain stuff,
> and everything in a certain group goes onto that page
> (I thought that was the intention of groups anyway).
> 
> However, instead the group page only contains the
> general documentation, the functions that I added to
> the group only appear on the namespace page and their
> Detailed Information disappears completely...
> 
> I've attached a small tar ball called 'doxybug.tar.gz'.
> Extract it and it will create a directory 'doxybug'.
> cd into doxybug/documentation/ and type 'make'.
> 
> Next look at doxybug/documentation/html/namespacelibcw_1_1debug.html
> and you will find that it contains the two functions,
> which SHOULD have gone into 
> doxybug/documentation/html/group__demangle.html
> 
> Looking at doxybug/documentation/html/group__demangle.html you'll
> see that it only contains the data from demangle3.cc.
> The detailed info is no where (although this is the page that we
> get to when you click 'more...' after the functions).
> 
> Note that if you remove the *code* (namespace libcw {... etc)
> in demangle3.cc, then everything works as I want it to work.
> 
> -- 
> Carlo Wood <ca...@al...>
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> 


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
pos...@ra....

This footnote also confirms that this email message has been scanned
for the presence of computer viruses known at the time of sending.

www.radioscape.com
**********************************************************************

RE: [Doxygen-users] Making an Easy and fast readable C Library Manual reference.(TODO-Suggestions)

[Stephen G. <ste...@el...>]

Ah, well, there we must part in our ways: I'm afraid that I firmly
believe in restructuring my library architecture (both logical and
physical) if that can help make things clearer. Over the 10-plus years
that my own pet library has been in existence it has been restructured
from top to toe at least three times :-) Nowadays, I do try to restrict
the impact that such structuring has on the public interface, but I feel
at liberty to modify the internals, or new material, at the drop of a
hat.

The single small item I happened to mention (using two levels of
directory to separate public and private interface) was done years
before I even started to use Doxygen: it just happens that that
separation does make it easier to produce good docs - but pretty much
the same result could be reached with more work on the configuration
files (if one has the energy to do that).

Having said that, I _am_ actively fiddling with another part of my
physical design (relating to where/how to arrange examples) simply so
that I _can_ get perfect documentation (hopefully whilst still keeping
to my other goals regarding that code): if I ever manage that then it'll
be put up for public ridicule^h^h^h^h^h^h^h^h acclaim :-) If the
documentation were better, more people would use this library (they
might even _want_ to use it) and I'd feel a fool if I prevented that
because I'd been precious about my wonderful design :-)

Regards,
Stephen Goudge

> -----Original Message-----
> From: dox...@li...=20
> [mailto:dox...@li...] On Behalf=20
> Of Toni Moreno Gim=E9nez
> Sent: 20 November 2001 18:24
> To: Stephen Goudge; dox...@li...
> Subject: Re: [Doxygen-users] Making an Easy and fast readable=20
> C Library Manual reference.(TODO-Suggestions)
<snip>
>=20
> ( and I think is a bad goal , to change architecture design=20
> features only for=20
> doxygen doc generation , Doxygen like a source code=20
> documentation tool may=20
> addapt to any design , I was been studing and working on my=20
> lib design for 2=20
> years and I will not change it , expecting for a perfect=20
> documentation)
>=20
>=20
>=20
> --=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Toni Moreno Gim=E9nez
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Pje de las rosas  n=BA 22
> Vilassar de Mar=20
> (Barcelona) Espa=F1a
> CP: 08340

Re: [Doxygen-develop] Re: [Doxygen-users] Making an Easy and fast readable C Library Manual reference.(TODO-Suggestions)

[Toni M. <ton...@wa...>]

> > I CAN'T HIDE MACRO BODY....
>
> Then you are doing something wrong!
>
> Using:
>
> /** \file */
>
> /** Docs here.
>  *  \hideinitializer
>  */
> #define GSDATAFORMAT_GET_FORMAT_WITHOUT_ENDIANES( __fmt )             \
>       ({ register guint __v;                                          \
>        if ( (((__fmt) & FORMAT_BYTEORDER_LE)>>4) ^                    \
>          (((__fmt) & FORMAT_BYTEORDER_BE)>>5) )                       \
>        __v=3D((__fmt) & ~GSDATAFORMAT_BYTEORDER_MASK);                 =
 \
>        else __v=3D(__fmt);                                             =
 \
>        __v;                                                           \
>        })
>
> /*! An enum */
> typedef enum
> {
>   val =3D 10 /*!< \hideinitializer enum value */
> } MyEnum;
>
> With a default config file, I get no initializer for defines or enums.

The enums runs OK thanks...
But i can't hide macros.

I have tested 4 ways.


1) ----------------------------------------
/** \def GSDATACHANNELSYS_GET_NUMCH
*       Gets the number of channels
*=09
*/

#define GSDATACHANNELSYS_GET_NUMCH(__chsys)\
        ((__chsys) & GSDATACHANNELSYS_NUMCH_MASK)

2) ----------------------------------------
/** \def GSDATACHANNELSYS_GET_NUMCH
*       Gets the number of channels
*	\hideinitializer=09
*/

#define GSDATACHANNELSYS_GET_NUMCH(__chsys)\
        ((__chsys) & GSDATACHANNELSYS_NUMCH_MASK)



3) ------------------------------------------
/** \def GSDATACHANNELSYS_GET_NUMCH
*       Gets the number of channels
*
*/
#define GSDATACHANNELSYS_GET_NUMCH(__chsys)\
        (\
        ((__chsys) & GSDATACHANNELSYS_NUMCH_MASK)\
        )

4) ------------------------------------------
/** \def GSDATACHANNELSYS_GET_NUMCH
*       Gets the number of channels
*	\hideinitializer
*/
#define GSDATACHANNELSYS_GET_NUMCH(__chsys)\
        (\
        ((__chsys) & GSDATACHANNELSYS_NUMCH_MASK)\
        )

--------------------------------------------

The Html Output for 3 and 4 cases are "exactly" the same  independent of =
the=20
\hideinitializer tag
In 3 and 4 cases the DEFINES section dont show the body of the macro but
the DEFINES DOCUMENTATIONS section continues showing it.

The output for 1 and 2 cases are "exactly" the same independent of the=20
\hideinitializer tag. Where the html ouput shows body macro in both secti=
ons
DEFINES section and DEFINES DOCUMENTATION section.

Perhaps I'm doing something wrong but i can't  solve it.


I have atached , my config file and a header source code for testing your=
self.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Toni Moreno Gim=E9nez
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pje de las rosas  n=BA 22
Vilassar de Mar=20
(Barcelona) Espa=F1a
CP: 08340
-----------------
Tel:937598149
Tel: 699706656
-----------------

[Doxygen-users] Bug related to grouping and namespaces.

[Carlo W. <ca...@al...>]

I am having problems with grouping.
The need is to create a seperate page for certain stuff,
and everything in a certain group goes onto that page
(I thought that was the intention of groups anyway).

However, instead the group page only contains the
general documentation, the functions that I added to
the group only appear on the namespace page and their
Detailed Information disappears completely...

I've attached a small tar ball called 'doxybug.tar.gz'.
Extract it and it will create a directory 'doxybug'.
cd into doxybug/documentation/ and type 'make'.

Next look at doxybug/documentation/html/namespacelibcw_1_1debug.html
and you will find that it contains the two functions,
which SHOULD have gone into doxybug/documentation/html/group__demangle.html

Looking at doxybug/documentation/html/group__demangle.html you'll
see that it only contains the data from demangle3.cc.
The detailed info is no where (although this is the page that we
get to when you click 'more...' after the functions).

Note that if you remove the *code* (namespace libcw {... etc)
in demangle3.cc, then everything works as I want it to work.

-- 
Carlo Wood <ca...@al...>

Re: [Doxygen-users] Making an Easy and fast readable C Library Manual reference.(TODO-Suggestions)

[Carlo W. <ca...@al...>]

On Tue, Nov 20, 2001 at 08:06:24AM -0000, Stephen Goudge wrote:
> So in your example, all of the headers would be moved down into the m/
> directory, except for the four you've identified as "documented ones".

I tried the equivalent of just putting those four in the INPUT field.
But that doesn't work: all those header files DO contain documentation,
they just shouldn't be included by the user directly.  I don't want
them listed.

If I do what you suggest I get this:

~/c++/libcw_branch-threading/src/libcwd/documentation>make
doxygen doxygen.config
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:293 Warning: member `init' of class `debug_channels_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:333 Warning: member `init' of class `debug_objects_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:383 Warning: member `ST_uninit' of class `debug_objects_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:451 Warning: member `calculate_capacity' of class `debug_string_ct' cannot be found/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:464 Warning: member `NS_internal_init' of class `debug_string_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:473 Warning: member `ST_internal_deinit' of class `debug_string_ct' cannot be found/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:478 Warning: member `internal_assign' of class `debug_string_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:487 Warning: member `internal_append' of class `debug_string_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:496 Warning: member `internal_prepend' of class `debug_string_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:504 Warning: member `reserve' of class `debug_string_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:515 Warning: member `internal_swallow' of class `debug_string_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:525 Warning: member `push_margin' of class `debug_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:536 Warning: member `pop_margin' of class `debug_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:549 Warning: member `push_marker' of class `debug_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:559 Warning: member `pop_marker' of class `debug_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:572 Warning: no matching class member found for void start(LIBCWD_TSD_PARAM)
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:711 Warning: member `finish' of class `debug_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:832 Warning: member `fatal_finish' of class `debug_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:838 Warning: member `NS_init' of class `debug_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:942 Warning: member `~debug_ct' of class `debug_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:1044 Warning: member `NS_initialize' of class `channel_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:1122 Warning: member `NS_initialize' of class `fatal_channel_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:1158 Warning: member `NS_initialize' of class `continued_channel_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:1164 Warning: member `off' of class `channel_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:1174 Warning: member `on' of class `channel_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:1194 Warning: member `operator|' of class `channel_set_st' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:1220 Warning: member `operator|' of class `debug_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:1254 Warning: member `operator|' of class `debug_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debug.cc:1260 Warning: member `operator &' of class `debug_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debugmalloc.cc:1675 Warning: member `register_marker' of class `marker_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/debugmalloc.cc:1699 Warning: member `~marker_ct' of class `marker_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/bfd.cc:1149 Warning: member `M_pc_location' of class `location_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/bfd.cc:1312 Warning: member `clear' of class `location_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/bfd.cc:1325 Warning: member `location_ct' of class `location_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/bfd.cc:1340 Warning: member `move' of class `location_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/bfd.cc:1354 Warning: member `operator=' of class `location_ct' cannot be found
/home/carlo/c++/libcw_branch-threading/src/libcwd/include/libcw/debug.h:163 Warning: reference to unknown section control_flags in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/include/libcw/debug.h:189 Warning: reference to unknown section control_flags in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/deallocation_pointer_validation.dox:3 Warning: link to unknown entity `enable_libcwd_magic' in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/deallocation_pointer_validation.dox:3 Warning: reference to unknown section invisible in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/location.dox:3 Warning: link to unknown entity `enable_libcwd_libbfd' in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/location.dox:3 Warning: link to unknown entity `enable_libcwd_location' in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/location.dox:3 Warning: link to unknown entity `BFD' in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/location.dox:3 Warning: link to unknown entity `enable_libcwd_location' in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/location.dox:3 Warning: link to unknown entity `Debug_Channel_objects' in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/location.dox:3 Warning: link to unknown entity `Allocated_memory_Overview' in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/location.dox:3 Warning: link to unknown entity `libcw::debug::alloc_ct::location' in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/preparation.dox:3 Warning: reference to unknown section configuration in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/reference.dox:1 Warning: reference to unknown section libcw::debug::debug_ct in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/reference.dox:1 Warning: reference to unknown section libcw::debug::channel_ct in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/reference.dox:1 Warning: reference to unknown section debug_ct_formatting in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/reference.dox:1 Warning: reference to unknown section control_flags in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/reference.dox:1 Warning: reference to unknown section ForAllDebugObjects in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/reference.dox:1 Warning: reference to unknown section ForAllDebugChannels in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/reference.dox:1 Warning: link to unknown entity `libcw::debug::check_configuration' in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/documentation/reference.dox:1 Warning: link to unknown entity `libcw::debug::make_all_allocations_invisible_except' in the documentation of this entity!
/home/carlo/c++/libcw_branch-threading/src/libcwd/demangle3.cc:15 Warning: reference to unknown section type_info_of in the documentation of this entity!

In other words, the header ARE input files.

-- 
Carlo Wood <ca...@al...>

Re: [Doxygen-users] Documenting a "libray reference Manual" using Doxygen.

[Carlo W. <ca...@al...>]

On Tue, Nov 20, 2001 at 11:08:03AM +0100, Prikryl,Petr wrote:
> In the context of my previous comments, I disagree with hiding
> explicitly stated values of enum items as the default behaviour.
> I even think that nothing should be changed.

Make the default behaviour configurable and allow to toggle
the behaviour per enum with some command.  The is no reason
not to do that, and there clearly exist the need for this
with some users.

-- 
Carlo Wood <ca...@al...>

Re: [Doxygen-develop] Re: [Doxygen-users] Making an Easy and fast readable C Library Manual reference.(TODO-Suggestions)

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

On Tue, Nov 20, 2001 at 07:05:56PM +0100, Toni Moreno Giménez wrote:
> El Mar 20 Nov 2001 06:25, Dean Povey escribió:
> > <snip>
> >
> > Let me add a big ditto to most of this.  Doxygen is great, but I find it
> > is almost, but not quite there for documenting C code.
> >
> > >2) * hide Macro definitions body. ( and document them like functions )
> >
> > You can hide macro body with @hideinitializer.  It would be good to be able
> 
> /** \def GSDATAFORMAT_GET_FORMAT_WITHOUT_ENDIANES
> *       \hideinitializer
> */
> 
> the outputs is....
> 
>  #define GSDATAFORMAT_GET_FORMAT_WITHOUT_ENDIANES( __fmt ) 
> Value:({ register guint __v;                                          \
>          if ( (((__fmt) & FORMAT_BYTEORDER_LE)>>4) ^                    \
>               (((__fmt) & FORMAT_BYTEORDER_BE)>>5) )                    \
>          __v=((__fmt) & ~GSDATAFORMAT_BYTEORDER_MASK);                  \
>          else __v=(__fmt);                                              \
>          __v;                                                           \
>          })
> 
> I CAN'T HIDE MACRO BODY.... 

Then you are doing something wrong!

Using:

/** \file */

/** Docs here.
 *  \hideinitializer 
 */
#define GSDATAFORMAT_GET_FORMAT_WITHOUT_ENDIANES( __fmt )             \
      ({ register guint __v;                                          \
       if ( (((__fmt) & FORMAT_BYTEORDER_LE)>>4) ^                    \
         (((__fmt) & FORMAT_BYTEORDER_BE)>>5) )                       \
       __v=((__fmt) & ~GSDATAFORMAT_BYTEORDER_MASK);                  \
       else __v=(__fmt);                                              \
       __v;                                                           \
       })

/*! An enum */
typedef enum
{
  val = 10 /*!< \hideinitializer enum value */
} MyEnum;

With a default config file, I get no initializer for defines or enums.

If you get tired of typing \hideinitializer, then set
MAX_INITIALIZER_LINES to 0 to hide all initializers
automatically and use \showinitializer at those place
where values are needed. 

Regards,
  Dimitri

Re: [Doxygen-users] Making an Easy and fast readable C Library Manual reference.(TODO-Suggestions)

[Toni M. <ton...@wa...>]

> Let me add a big ditto to most of this.  Doxygen is great, but I find i=
t
> is almost, but not quite there for documenting C code.

I'm agree. But I think not much work is needed to get a better C=20
documentation using doxygen. =20
About Object Oriented C style , I think is not needen because we can work=
 on=20
\defgroup and \addgroup , to get a good doc structure. ( avoiding use the=
=20
\file tag) .

Inheritance structures can be easyly made using \ingroup ( Is what I'm do=
ing).

And I only miss , control on the order of modules or groups.

Y have put the correct order in my INPUT section
but the order in the tree browser is in reverse order (Perhaps a BUG????)

My input section....
------------------------------------
INPUT     =3D        ./src/gsound.h \    <---here  \defgroup Gsound Init
                       ./src/gsmathdefs.h \  <--- here \defgroup Gsound u=
tils
                       ./src/data/gsdata.h \	<--here \gsdata
                       ./src/data/gsdataformat.h \	<--here \GsDataFormat
                      ./src/data/gsdatachannelsys.h \
                      ./src/data/gsdatatimeenv.h \
                      ./src/data/gsdatatime.h \
                      ./src/data/gsdatabuffer.h \
                     ./src/data/gsdatawave.h \
		etc...
		....

This is the output tree browser:
-------------------------------------------
MODULES (browser)

....
Gsound Basics and Tools.=20
	Gsound Constants and utils=20
	Gsound Initialization.  <----First defined and last in the browser
GSound : Basic Data Types=20
	GsDataWave=20
	GsDataBuffer=20
	GsDataTime=20
	GsDataTimeEnv=20
	GsDataChannelSys=20
	GsDataFormat     <----First defined and last in the tree browser
.....
etc
.....
---------------------------------------------

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Toni Moreno Gim=E9nez
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pje de las rosas  n=BA 22
Vilassar de Mar=20
(Barcelona) Espa=F1a
CP: 08340

Re: [Doxygen-users] Making an Easy and fast readable C Library Manual reference.(TODO-Suggestions)

[Toni M. <ton...@wa...>]

> You can then start to get clever : Your public documentation has
> Doxygen's recursive input switched off. If you have a second config fil=
e
> with the recursion switched on and looking for the dot-c/dot-cpp files
> as well, bingo, nicely formatted documentation of the internals of the
> library for anyone who needs to maintain it :-)

I'm working on two config files.

doxyfile.refman
doxyfile.devel

the first have switched off the recursive option. the input secction has =
a=20
list of header files :
INPUT	=3D 	<myobject1.h> \
		<myobject2.h> \
		...
		<myobjectX.h>=20


The second one ,recursive tag is switched on.

When the reference manual are generated, secction FILES shows all=20
<myobjectX.h> , but the user should only include in your applications.=20
<mylib.h>.

I can move files to adapt  the documentation, because the doc tags are=20
written in <myobjectX.h>=20

( and I think is a bad goal , to change architecture design features only=
 for=20
doxygen doc generation , Doxygen like a source code documentation tool ma=
y=20
addapt to any design , I was been studing and working on my lib design fo=
r 2=20
years and I will not change it , expecting for a perfect documentation)



--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Toni Moreno Gim=E9nez
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pje de las rosas  n=BA 22
Vilassar de Mar=20
(Barcelona) Espa=F1a
CP: 08340

Re: [Doxygen-users] Making an Easy and fast readable C Library Manual reference.(TODO-Suggestions)

[Toni M. <ton...@wa...>]

El Mar 20 Nov 2001 06:25, Dean Povey escribi=F3:
> <snip>
>
> Let me add a big ditto to most of this.  Doxygen is great, but I find i=
t
> is almost, but not quite there for documenting C code.
>
> >2) * hide Macro definitions body. ( and document them like functions )
>
> You can hide macro body with @hideinitializer.  It would be good to be =
able

/** \def GSDATAFORMAT_GET_FORMAT_WITHOUT_ENDIANES
*       \hideinitializer
*/

the outputs is....

 #define GSDATAFORMAT_GET_FORMAT_WITHOUT_ENDIANES( __fmt )=20
Value:({ register guint __v;                                          \
         if ( (((__fmt) & FORMAT_BYTEORDER_LE)>>4) ^                    \
              (((__fmt) & FORMAT_BYTEORDER_BE)>>5) )                    \
         __v=3D((__fmt) & ~GSDATAFORMAT_BYTEORDER_MASK);                 =
 \
         else __v=3D(__fmt);                                             =
 \
         __v;                                                           \
         })

I CAN'T HIDE MACRO BODY....=20

> to add information about the type of macro parameters and expected retu=
rns
> where relevant.  Also it would be nice to be able to abstract the fact =
that
> a macro is a macro and not a function, as sometimes you want to switch
> between functions and macros.

The internal designs don't let me do so.

if you see this.

#define GSDATAFORMAT_GET_FORMAT_WITHOUT_ENDIANES( __fmt )=20
	__fmt : a format enum
	macro returns:  the same format without endiantes format info.

you are completely sure that your are using a Macro not a function.


--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Toni Moreno Gim=E9nez
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pje de las rosas  n=BA 22
Vilassar de Mar=20
(Barcelona) Espa=F1a
CP: 08340

RE: [Doxygen-users] Documenting a "libray reference Manual" using Doxygen.

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

Hi Carlo and other doxygeners,

Carlo Wood wrote...
> On Mon, Nov 19, 2001 at 06:27:04PM +0100, Toni Moreno Gim=E9nez =
wrote:
> > library users need  ONLY. to know the label of each format type.
>=20
> I agree.  The nature of enums is such that in general the value
> is 'internal', and showing it to a user messes up the cleanness
> of the documentation as it is not relevant.

I think that it is not the case of C/C++.  If one does need any
conversion, then he/she should not assign the explicit values.
If explicit values are assigned to the items, then they are probably=20
intended to be used for conversions to integer types, and this=20
should be visible.  Doxygen shows only explicitly stated values.=20

> In SOME cases it is important to know the values, when enums
> are correlated somehow, but that is in general Bad Programming
> then (and constant integers should have been used instead).

I also think that using enums without explicit values is somehow
cleaner.  But if you need to assign the enum item the explicit value,
then you should know why.  In other words, if you assign the enum
constants the explicit values and you don't need the explicit values,
then it is a bad programming practice.  But if you really need that,
then the situation should be made visible.

> The default should be NOT to show enum values.  An option
> *per* enum could be added to show it.

In the context of my previous comments, I disagree with hiding
explicitly stated values of enum items as the default behaviour.
I even think that nothing should be changed.

(Note: Toni Moreno Gim=E9nez uses enum with values defined this way.)
> > typedef enum  GsDataFormat {=20
> >   GSDATAFORMAT_SI8 =3D=20
> > GSDATAFORMAT_SET_INT(FORMAT_SIGNED,FORMAT_BYTEORDER_NE,1),=20
> > [...]
> > }

Toni should use some different (possibly non automatic) kind of =
documenting
such enum values).

Your opinion?
  Petr

Re: [Doxygen-users] Documenting a "libray reference Manual" using Doxygen.

[Johan E. <joh...@ua...>]

Hi guys,
            has anyone tested the configuration option=20
MAX_INITIALIZER_LINES, I did that for enums by setting it to zero and=20
then the value disappeared......I don't know if this solves your=20
problems with different defines, enums, etc. but to introduce another=20
command like \show_values, \show_definition seems to be overkill since=20
it already exists the commands \showinitializer and \hideinitializer......

In general, I think it is good to provide different options to customize=20
e.g. a tool. However, when/if the options starts to depend on each in=20
one way or another, the complexibility to maintain and test the=20
different combinations increases (exponential?) especially as for a tool=20
like Doxygen where a number of output formats is also provided....

I think for Doxygen, it provides a lot of options already and adding new=20
options should be considerred very carefully (which I am sure of is done=20
by Dimitri) and instead concentrate of developing the tool with=20
increased functionality like e.g. the xml parser.

Just some thoughts,
                             Johan

Carlo Wood wrote:

>On Mon, Nov 19, 2001 at 06:27:04PM +0100, Toni Moreno Gim=E9nez wrote:
>
>>library users need  ONLY. to know the label of each format type.
>>
>
>I agree.  The nature of enums is such that in general the value
>is 'internal', and showing it to a user messes up the cleanness
>of the documentation as it is not relevant.
>In SOME cases it is important to know the values, when enums
>are correlated somehow, but that is in general Bad Programming
>then (and constant integers should have been used instead).
>
>The default should be NOT to show enum values.  An option
>*per* enum could be added to show it.  For example:
>
>/**
> * \show_values
> */
>enum foo {
>...
>
>Same thing for macro functions, in general the definition of
>the macro should be hidden and only shown when explicitely
>requested:
>
>/**
> * \show_definition
> */
>#define FOO(x) (x * x * x - 2 * x + 3)
>

Re: [Doxygen-users] Making an Easy and fast readable C Library Manual reference.(TODO-Suggestions)

[Stephen G. <ste...@el...>]

I always try to develop code as libraries and, for anything but the most
trivial cases, also end up with one or two headers that the users of the
library need to include and a whole bunch that are only used between
compilation units within the library. This has held true whatever the
more general style of coding (C++, "plain C", "Object-style C",
whatever). In this situation, regardless of whether Doxygen is being
used or not, I have found that the best answer is just to introduce some
physical design into the setup. The one I start with looks like, for a
library called "baz",:

<my-work-area>/baz/
 -- holds all the public headers and the top-level Makefile

<my-work-area>/baz/m/
 -- holds the dot-c, dot-cpp files (compilation units) AND the
internal-use-only headers

So in your example, all of the headers would be moved down into the m/
directory, except for the four you've identified as "documented ones".

With this arrangement, before the introduction of Doxygen, there is
already scope for doing Interesting Things - eg, if someone wants a
pre-compiled set of all the libraries and the headers, a script can just
collect all of the <my-work-area>/*/ directories - so long as it doesn't
recurse any deeper it'll pick up only the public interface headers. And
of course humans can do the same thing ("Which of these files should I
be interested in?" "Just the ones in this directory"). You can also trim
down some of those convoluted header names, such as
"private_internal_xxxx.h" - this just becomes "m/xxxx.h".

When you add Doxygen into the equation you then have a very simple task:
just ask it to read all the headers in the <my-work-area>/baz/
directory. No need for special configuration directives to "hide headers
that have been explicitly not documented".

You can then start to get clever : Your public documentation has
Doxygen's recursive input switched off. If you have a second config file
with the recursion switched on and looking for the dot-c/dot-cpp files
as well, bingo, nicely formatted documentation of the internals of the
library for anyone who needs to maintain it :-)

Regards,
Stephen Goudge

> -----Original Message-----
> From: dox...@li...=20
> [mailto:dox...@li...] On=20
> Behalf Of Carlo Wood
> Sent: 20 November 2001 05:00
> To: Toni Moreno Gim=E9nez
> Cc: dox...@li...;=20
> dox...@li...
> Subject: [Doxygen-develop] Re: [Doxygen-users] Making an Easy=20
> and fast readable C Library Manual reference.(TODO-Suggestions)
>=20
>=20
> On Tue, Nov 20, 2001 at 04:37:37AM +0100, Toni Moreno Gim=E9nez wrote:
> > 3) (Disable File List Section)
> >
> > If you are documenting a like "Object Oriented C code" is=20
> common use a=20
> > couple of source code files for each "object."
> >
> > myobject.c
> > myobject.h
> >
> > But the final library usually have and unique header to include. By=20
> > example mi lib has while developing the first release aprox=20
> 25 headers
> >
> > but only one is needed to use the lib.
>=20
> Same thing here, at least I should be able to hide heaader=20
> files that I explicitely NOT documented (didn't add a \file=20
> in). Doxygen now generates this page:
>=20
> Here is a list of all documented files with brief=20
> descriptions: libcw/bfd.h [code]
> libcw/buf2str.h [code]			Definition of=20
> utility class buf2str
> libcw/char2str.h [code]			Definition of=20
> utility class char2str
> libcw/class_alloc.h [code]
> libcw/class_channel.h [code]
> libcw/class_channel_set.h [code]=20
> libcw/class_continued_channel.h [code] libcw/class_debug.h=20
> [code] libcw/class_debug_string.h [code]=20
> libcw/class_fatal_channel.h [code] libcw/class_location.h=20
> [code] libcw/class_marker.h [code] libcw/control_flag.h=20
> [code] libcw/core_dump.h [code]
> libcw/cwprint.h [code]			Definition of=20
> the utilities cwprint and cwprint_using
> libcw/debug.h [code]			This is the main header=20
> file of libcwd
> libcw/debug_config.h [code]
> libcw/debugmalloc.h [code]
> libcw/demangle.h [code]
> libcw/enum_memblk_types.h [code]
> libcw/lockable_auto_ptr.h [code]=20
> libcw/macro_ForAllDebugChannels.h [code]=20
> libcw/macro_ForAllDebugObjects.h [code]=20
> libcw/macro_Libcwd_macros.h [code] libcw/max_label_len.h=20
> [code] libcw/pc_mangled_function_name.h [code]=20
> libcw/private_allocator.h [code] libcw/private_assert.h=20
> [code] libcw/private_debug_stack.h [code]=20
> libcw/private_internal_string.h [code]=20
> libcw/private_internal_stringstream.h [code]=20
> libcw/private_internal_vector.h [code]=20
> libcw/private_set_alloc_checking.h [code]=20
> libcw/private_threading.h [code] libcw/private_TSD.h [code]=20
> libcw/strerrno.h [code] libcw/sysd.h [code] libcw/type_info.h [code]
>=20
> while I only want the four documented ones to appear.
> The user NEVER has to #include any other.
>=20
> --
> Carlo Wood <ca...@al...>
>=20
> _______________________________________________
> Doxygen-develop mailing list Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>=20
>=20