doxygen-develop — List for discussing new features, submitting patches, etc.

[Doxygen-develop] Windows binaries available for Doxygen-1.3.4-20031103

[Petr P. <Pr...@sk...>]

(Sorry for the delay -- problems with compilation.)

Hi,
=20
If interested, you can download the doxygen binaries
compiled for MS Windows from
=20
  http://doxygen.sourceforge.net/dl/doxygen-1.3-cvs/
=20
This is the place where you should find also the next
releases.  The name of the archive is constructed=20
from the date of CVS release.
=20
The binaries are NOT created automatically, so it may
happen that some newer CVS sources were not compiled
because I am not present to do that or I forgot... ;)
=20
Regards,
  Petr
=20
--=20
Petr Prikryl (prikrylp at skil dot cz)

[Doxygen-develop] Simple @todo improvements?

[Luna K. <lis...@ne...>]

Hi,

(I'm new to Doxygen, so I apologize if the things below are 
a matter of config settings. At the moment it seems they aren't.)

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

@todo items appear not to be collected globally (or on a
file level), irrespective of being in a special comment or 
not. Only those get listed that are in comments related
to classes, methods etc.

Is this true, or am I just missing something?

If so, this would be nice to amend, as many todo items are 
pretty generic things, very frequently not associated with 
any already existing language constructs, but are feature/
improvement/correction suggestions and ideas etc. on a 
project-global or a module/file level.

In my practice, the "global" todo stuff is actually far 
more important than the "fixme"-like comments relevant to 
certain code constructs (classes etc.). So, given that 
Doxygen already supports the latter very nicely, it would 
be quite natural to do same for the global ones, too.

(The Related Pages --> Todo List is already straightforward 
place for listing the project-global @todo items, as is the 
File List for the file-global todo item collections.)

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

Another thing: developers tend to have their own todo listings
already, somewhere at the beginning or end of a file, usually 
formatted simply like e.g.:

/* TODO:

    - This is something to do.

    - And this one is a very common multi-line
      todo item.

    - And here comes a third one, which is not only
      multi-line, but is a multi-paragraph one.

      (Can also possibly contain URLs, code fragments, 
      but all properly indented.)
         
*/

It would be extremely helpful if Doxygen could take care 
of these and could include these existing lists without 
forcing the programmer

    - to unnaturally attach the comment block to some 
      language construct [again, this may not be true, 
      I'm a Doxygen newbie, and I might have just missed 
      something in the docs.]

    - placing a "@todo" before each and every item on
      the list, likely breaking his formatting style and 
      possibly also the compatibiliy with his already 
      existing todo-management stuff.

Ideally, a simple code change like this should be enough:

/** @todo:

    - This is something to do.

    - And this one is a multi-line
      todo item.

    - And here come a third one, which is not only
      a multi-line one, but even a multi-paragraph one.

      (Can also possibly contain URLs, code fragments, 
      but all properly indented.)
*/

(I'd say an upper-case @TODO should also be accepted, but
that's just a personal itch.)

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

BTW, if the user happens to already have some TODO management
logic in place already, where he also handles component-level 
TODO items (the subset Doxygen appears to support), he probably 
also uses some markup, similar to Doxygen's, but most likely 
not the same, like: !!TODO or [TODO:] or whatever.

It would be incredibly helpful if Doxygen would allow changing
the pattern by which it can find a todo/bug/... item!

(Of course this flexibility would be very handy for most of 
the other pattern constructs, too, but I digress...)

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

OK, thanks for your patience!

Cheers,
Sz.

[Doxygen-develop] PATCH: class-list order

[Boaz K. <boa...@ya...>]

Consider this scenario:

/// Proj
namespace PROJ {
    /// Foo
    namespace FOO {
        /// Class %A
        class A {};
        /// Class %C
        class C {};
    }
    /// Bar
    namespace BAR {
        /// Class %B
        class B {};
        /// Class %D
        class D {};
    }
}

Currently, classes in the Class List are sorted by 
class name, ignoring namespaces:

  PROJ::FOO::A
  PROJ::BAR::B
  PROJ::FOO::C
  PROJ::BAR::D

I'd like classes (compounds) to be sorted by 
fully qualified scoped names:

  PROJ::BAR::B
  PROJ::BAR::D
  PROJ::FOO::A
  PROJ::FOO::C

This little example may seem silly, but it's a
simplification of real projects, where namespaces
encapsulate independent components -- packages
or modules if you like; in these projects
the current sort order can be confusing.

The attached patch introduces a new configuration
option SORT_BY_SCOPED_NAMES which, if enabled,
sorts the class-list based on fully-qualified 
scoped names.
Another configuration option CASE_SENSITIVE_SORT 
controls whether the sorting of the class-list is 
case-sensitive or not.
The default values of both options preserve the
current behavior.

Notes: 
1) This patch changes the way the global class
   list (Doxygen::classSDict) is sorted; it could be
   that this might affect other things I wasn't aware
   of (i.e that it introduces bugs ;-(); if it does,
   please let me know.
2) The patch changes only the class-list sort order;
   it doesn't affect the alphabetical list or other
   lists -- this addresses my own project's needs;
   It could be that more general settings
   regarding sorting criteria might be helpful;
   let me know what you think.

-- Boaz


__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

[Doxygen-develop] PATCH: date/time format

[Boaz K. <boa...@ya...>]

Currently, date/time strings in the generated 
documentation are based on local-time, and appear
in a fixed (hard-coded), English-based format.
I'd like to have better control on the format,
and optionally use UTC time.
The attached patch introduces three new 
configuration options:
  DATETIME_FORMAT strftime(3) format for date/time
  DATE_FORMAT     strftime(3) format for date
  UTC_DATETIME    if YES, use UTC time; else use local time

The default values for these options preserve the
current behavior (but see caveat below).

Caveat: The resulting date/time strings might be 
        locale-dependent. To correctly emulate the
        current behavior, one must set the environment
        to use the default (C) locale before running doxygen.

Portability note: The new code should work on all Unix-like
systems, as well as Windows (at least with MS Visual C++).
The existing code uses Qt code that seems to also support 
OS/2 and DOS, which the new code, most likely, does _not_
support. I wasn't sure if doxygen itself is expected to support
these platforms; to be on the safe side, the new code is 
conditioned on not being executed in any of these platforms,
so if doxygen used to work there, it should still work, only
without these new options. If these platforms are not really
supported, some #ifdef's and #ifdef'ed code (all marked with
FIXME comments) can be safely removed.

-- Boaz

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

[Doxygen-develop] PATCH: doc typos

[Boaz K. <boa...@ya...>]

The attached patch fixes some typos in the
documentation of the configuration options.
-- Boaz

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

[Doxygen-develop] doxygen and Hitachi Embedded Workshop

[Rajendra K. A.V <raj...@ne...>]

Hello All,
         I am new to doxygen source. Can any boady give me some hint to
add support for doxygen-wizard for reading Hitachi Embedded
Workshop workspace file and generate configuration.

With Regards,
Rajendra.

Rajendra Kumar A.V.
Senior Engineer-Embedded.
NetIndia Pvt. Ltd.
#6-1-85/8,Satya Sadan,
Opp.Telephone Bhavan,
Saifabad,Lakdi-ka-pul,
Hyderabad-500004.
Andhra Pradesh.
India.
PHONE #: 040-23211454/452/553,
         040-55579584
FAX   #: 040-23211466





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

This Message and any attachments is intended solely for the addresses and is confidential. 
If you receive this message in error or if you are not the intended recipient, please delete the mail. 
Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited.
Please inform us in case of erroneous delivery, thanks for your cooperation.

[Doxygen-develop] Re: trying to get involve

[Martin F. <mar...@gm...>]

On 26.10.2003 19:44:54 as...@cl... wrote:
> As i tried to compile windows doxygen. I downloaded the source from cvs
>  opened the file doxygen\wintools\Doxygen.dsw, but it gave me some error
>  message about doxysearch not been available . so i fixed this first prob=
lem
>  in removing the project from the workspace. and created the patch file t=
hat
>  i attached here. the solution still  does not compile  so i attached her=
e
>  the error messages. but before i try to fix these issues and create a pa=
tch
>  . I wanted to check with everyone if this was the right way of
> trying to help, and maybe what i am trying to do has already been fixed. 
> please keep me posted in there is anything i should/could  be doing?

There are a few other problems with the MSVC project file:
- The project "Doxygen" should made dependend on the project "qtools"
- The file "searchindex.cpp" should be included into the project "Doxygen".
- The file "packagedef.cpp" seams to be an old one - it should be removed f=
rom the project "Doxygen".
- The compiler option "/Zm400" has to be added to the Debug configuration t=
o overcome the default heap limitation, which shows up when compiling the X=
ML code.

After making this adjustments, the build is successfully.
If you want, I could send a diff file for this.

-- 
Martin Fuchs
mar...@gm...

Re: [Doxygen-develop] trying to get involve

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

On Sun, Oct 26, 2003 at 07:44:54PM +0100, as...@cl... wrote:
> As i tried to compile windows doxygen. I downloaded the source from cvs opened the file doxygen\wintools\Doxygen.dsw, but it gave me some error message about doxysearch not been available . so i fixed this first problem in removing the project from the workspace. and created the patch file that i attached here. the solution still  does not compile  so i attached here the error messages. but before i try to fix these issues and create a patch . I wanted to check with everyone if this was the right way of
> trying to help, and maybe what i am trying to do has already been fixed. 
> please keep me posted in there is anything i should/could  be doing?

Sending patches is good, but for windows it is good to use
"diff -bu", where the "b" option makes sure blanks are ignored (otherwise
the whole file is different only due to missing ^M's).

The errors you have are due to the files that are generated by flex and yacc
(from .l and .y files), which are in the source distribution but not in 
CVS (they are generated after all). 

To fix this in a nice way the project should add
custom build rules for the flex and yacc files. If you assume flex and yacc are
in the path this could even be done in a portable way. You could look at
src/libdoxygen.t for info how to call flex and yacc in order to generate the
missing files. 

Regards,
  Dimitri

[Doxygen-develop] configure what is a warning and what is an error

[Stefan K. <ko...@im...>]

hi Dimitri,

can I configure in doxygen, what is a warning and what is not.
e.g. to say that "Warning: Member XXX of YYY is not documeted ..."
should be treated as an error.

ciao
  Stefan
-- 
      \|/            Stefan Kost
     <@ @>           private            business
+-oOO-(_)-OOo------------------------------------------------------ - - -  -   -
|       __  Address  Simildenstr. 5     HTWK Leipzig, Fb IMN, Postfach 301166
|      ///           04277 Leipzig      04277 Leipzig
| __  ///            Germany            Germany
| \\\///    Phone    +49341 2253538     +49341 30766101
|  \__/     EMail    st_kost_at_gmx.net kost_at_imn.htwk-leipzig.de
|           WWW      www.sonicpulse.de  www.imn.htwk-leipzig.de/~kost/about.html
===-=-=--=---=---------------------------------- - - -  -    -

[Doxygen-develop] trying to get involve

[<as...@cl...>]

As i tried to compile windows doxygen. I downloaded the source from cvs op=
ened the file doxygen=5Cwintools=5CDoxygen.dsw, but it gave me some error =
message about doxysearch not been available . so i fixed this first proble=
m in removing the project from the workspace. and created the patch file t=
hat i attached here. the solution still  does not compile  so i attached h=
ere the error messages. but before i try to fix these issues and create a =
patch . I wanted to check with everyone if this was the right way of
trying to help, and maybe what i am trying to do has already been fixed. =

please keep me posted in there is anything i should/could  be doing?
thanks,
Kemal

[Doxygen-develop] doxygen and c++ templates, return types, alignment... (fwd)

[Michael L. <le...@ma...>]

Hello everybody,

I first was sending this eMail directly to Dimitri van Heesch I think it
was a bad idea (I am sorry) and hope that this mailing list is the right
place...

I am at the moment working on C++ library for numerical analysis
(http://sourceforge.net/projects/flens/). For the documentation we want to
use doxygen.  There's only a small problem that because of our heavy usage
of templates some things don't look as good as they could (IMO).  I made a
very small change in one of the doxygen sourcefiles to outline my idea and
would like to know your opinion about it...


The problem I see with the doxygen generated documentation is that
typenames in our library can become pretty long, like
 - MatrixReference<DenseMatrix<D> >
 - ListInitializerSwitch<flens::Matrix<typename Matrix::Data > >
 - ...

This makes the table for "Public Member Function" in a class documentation
kind of unreadable if one uses the format

   RETURN_TYPE   MEMBER_FUNCTION

where RETURN_TYPE is right aligned and MEMBER_FUNCTION is left aligned.
(e.g.: http://www.mathematik.uni-ulm.de/~lehn/flens/html/classflens_1_1MatrixReference.html)


My idea is to use 2 lines and the format

   RETURN_TYPE
   MEMBER_FUNCTION

both left-aligned.
(e.g.: http://www.mathematik.uni-ulm.de/~lehn/flens/html_modified/classflens_1_1MatrixReference.html)

I didn't have time to make myself more familiar with the doxygen source
code, but there two more things I thought about:

1) For the "Member Function Documentation" a format using 3 lines like

   CLASS_NAME
	RETURN_TYPE
        MEMBER_FUNCTION

would look good in my opinion.

2) Another problem seems to be caused by nested templates like:

   DenseMatrix<typename Promotion<VectorData, VectorData>::type >


what do you think about that in general?

thanks,
Michael

[Doxygen-develop] [Q] Can doxygen parsing "if defined(xxx)" in c

[<wh...@cu...>]

IEknbSBmYWlsZWQgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgaW4gQw0KDQpDYW4gbm90IHBhcnNp
bmcgIiNpZiBkZWZpbmVkKHh4eCkiIGJ1dCAiI2lmbmRlZiANCi8qKg0KICogQGZpbGUgc2FtcGxl
LmMNCiovDQoNCiNkZWZpbmUgRkVBVFVSRV9GTjENCg0KI2lmIGRlaW5mZWQoRkVBVFVSRV9GTjEp
DQoNCi8qKg0KICogQGZuIHZvaWQgZm4xKCkNCiAqIEBicmllZiBtb3JlLi4uDQogKi8NCnZvaWQg
Zm4xKCkNCnsNCn0NCiNlbmRpZg0K

[Doxygen-develop] Windows binary after the correction... (was RE: [Doxygen-users] Doxygen-1.3.4-20031019 in CVS)

[Petr P. <Pr...@sk...>]

The Windows binaries after the mentioned correction
was placed to=20

http://doxygen.sourceforge.net/dl/doxygen-1.3-cvs/doxygen_win32_20031019
b.zip

The earlier doxygen_win32_20031019.zip was NOT removed for the case that
something went wrong with the "b" version.

--=20
Petr Prikryl (prikrylp at skil dot cz)=20

> -----Original Message-----
> From: Dimitri van Heesch [mailto:di...@st...]=20
> Sent: Monday, October 20, 2003 10:21 PM
> To: dox...@li...
> Subject: Re: [Doxygen-users] Doxygen-1.3.4-20031019 in CVS
>=20
>=20
> On Mon, Oct 20, 2003 at 12:38:10PM +0200, Pablo Alvarado wrote:
> > Hello everybody,
> >=20
> > I've just got the latest version, but I get following error=20
> with our unchanged=20
> > project:
> >=20
> > ...
> > Generating index page...
> > Generating file index...
> > index.cpp<150>: Internal error: Requested unknown option=20
> > ANNOTATION_FROM_BRIEF!
> > Ready.
> >=20
> > After that, Doxygen terminates without generating anything.
> > I've also tried updating our configure file, but it didn't=20
> help.  Any ideas? =20
> > What I'm doing wrong?  Help!
>=20
> It is bug. I've fixed src/index.cpp and committed it to CVS,=20
> which should solve
> this problem. Disabling the alphabetical class index is=20
> another option.
>=20
> Regards,
>   Dimitri
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance=20
> to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>=20

[Doxygen-develop] Display of base classes in class hierarchy

[Martin F. <mar...@gm...>]

Hello,

I am using Doxygen to document a java project.
Now I look for a possibility to show the JDK base classes of my own classes
in the class hierarchie (textual and graphical display).
Is it currently only possible to show that classes, that Doxygen uses as
input files?
To integrate all the JDK source code is not really an alternative.
I tried this - it took one whole day to process all the code and gave me
more than 1 GB of output files!

If there is currently no option to achieve what I am hinting for, I would
like to try to extend Doxygen myself. May be some one can point me where to
look in the source code?

Thanks for any answer

-- 
Martin Fuchs
mar...@gm...

NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

[Doxygen-develop] Windows binaries available for Doxygen-1.3.4-20031019

[Petr P. <Pr...@sk...>]

Hi,
=20
If interested, you can download the doxygen binaries
compiled for MS Windows from
=20
  http://doxygen.sourceforge.net/dl/doxygen-1.3-cvs/
=20
This is the place where you should find also the next
releases.  The name of the archive is constructed=20
from the date of CVS release.
=20
The binaries are NOT created automatically, so it may
happen that some newer CVS sources were not compiled
because I am not present to do that or I forgot... ;)
=20
Regards,
  Petr
=20
--=20
Petr Prikryl (prikrylp at skil dot cz)

[Doxygen-develop] irc chanel

[asad <as...@cl...>]

Is there a irc chanel for development on doxygen? If yes please let me know
where.

 

 

[Doxygen-develop] Windows binaries available for Doxygen-1.3.4-20031005

[Petr P. <Pr...@sk...>]

Hi,
=20
If interested, you can download the doxygen binaries
compiled for MS Windows from
=20
  http://doxygen.sourceforge.net/dl/doxygen-1.3-cvs/
=20
This is the place where you should find also the next
releases.  The name of the archive is constructed=20
from the date of CVS release.
=20
The binaries are NOT created automatically, so it may
happen that some newer CVS sources were not compiled
because I am not present to do that or I forgot... ;)
=20
Regards,
  Petr
=20
--=20
Petr Prikryl (prikrylp at skil dot cz)

[Doxygen-develop] Re: [Doxygen-users] symbolic link path STRIP_FROM_PROMPT is not working (repost)

[Jeeva S C. <gci...@ho...>]

Jeeva> It would be nice if doxygen has RELATIVE_PATH_NAME
Jeeva> and PREPEND_TO_PATH configurables.

Dimitri> Another possibility would be to allow wildcards in the
Dimitri> STRIP_FROM_PATH tag so you could do STRIP_FROM_PATH = */src/

Sounds good.

I have seen projects with paths like src/main/src, src/main/inc or
src/mainmodule/submodule/src, src/mainmodule/submodule/inc
Hope STRIP_FROM_PATH = */src/ would handle these kind of
paths.

However IMHO, RELATIVE_PATH_NAME would work for most
of the cases.
 
jeeva> One another thing is with version 1.3.4 -g and -u options are not 
working.

Dimitri> ?? They work fine for me! What is the problem/output you get?

I am not able to reproduce this after I rebooted the system.
It must be some issue with my environment.

Thanks

Jeeva.

[Doxygen-develop] symbolic link path STRIP_FROM_PROMPT is not working (repost)

[Jeeva S C. <gci...@ho...>]

Hello,

I have configured doxgen to generate full file path name by setting
FULL_PATH_NAMES = YES and stripping leading PATH
string using STRIP_FROM_PATH = $(PWD)/.

Since my path is symbolically linked PATH, doxygen doesn't remove the
leading PATH string.
Ex.
 >pwd
 >/usr/home/jeeva/dev/src
however the real path is
/nfs/export/home/blah/blah/jeeva/dev/rev3.03/prod1/src

Is this an expected behavior or unknown feature (called as bug otherwise)?

I am using doxygen version 1.3.4.

It would be nice if doxygen has RELATIVE_PATH_NAME and PREPEND_TO_PATH
configurables.

One another thing is with version 1.3.4 -g and -u options are not working.

Please don't ignore this email.

Your help is appreciated.

Thanks

Jeeva.

[Doxygen-develop] Crash with 1.3.4

[George V. <gy...@ma...>]

Hello,

I have a project where I am getting a stack overflow exception with the 
stock 1.3.4 Win installer. The same project just compiled fine with 1.3.2.
I will not be able to send you samples. I also do not know if I will be 
able to debug the problem.

George Varga

Re: [Doxygen-develop] documenting c-struct members

[Michael D. <mi...@na...>]

On Friday 26 September 2003 20:46, Dimitri van Heesch wrote:
> On Fri, Sep 26, 2003 at 12:32:52PM +0200, Michael Daum wrote:
> > But I don't get exactly what I wanted. The c_struct is part of a group
> > (of related structures). The \var docu then goes into the group docu
> > (section Variables) and is marked 'inherited'. Actually I expected the
> > c_struct::field1 to be on the page documenting the c_struct.
>
> Me too. Are you sure only the c_struct is grouped? Or is the whole struct
> with everything in it grouped? This probably depends on whether @ingroup
> is used (good) or if the whole struct is in a @defgroup .. @{  ... @}
> block (bad in this case). Please provide an example to make it easier to
> discuss about the problem.

OK. 

Each headerfile is added to a group using @addtogroup. The implementations, which 
become part of that group aswell, are bundled into a c-file of the same
name. So I use @addtogroup for the c-file and the h-file. I think that's
what's intended to be done with those @addtogroups.

Here are three sniplets that (a) show how things work (b) how things don't
work as intended  and (c) how I'd like things to work.

(a) here's how things work right now, but which are inconvenient in terms
of code uglification.

/**
  @addtogroup MyGroup
  @{ 
*/

/**
  short descriptionof MyExportedTypeStruct.
  long description.
*/
typedef struct {
  int memberA; /**< lots of documentation here 
                             lots of documentation here 
                             lots of documentation here 
                             lots of documentation here 
                             lots of documentation here  */
  int memberB; /**< lots of documentation here
                             lots of documentation here 
                             lots of documentation here 
                             lots of documentation here 
                             lots of documentation here 
                             lots of documentation here 
                             lots of documentation here 
                             lots of documentation here 
                             lots of documentation here */
} MyExportedTypeStruct;
typedef MyExportedTypeStruct *MyExportedType; /**< type definition */

/** @} */

(b) here's how member documentation gets into the wrong place, that
is: onto the MyGroup page but not on the MyExportedTypeStruct page.

/**
  @addtogroup MyGroup
  @{ 
*/

/**
  short descriptionof MyExportedTypeStruct.
  long description.
*/
typedef struct {
  int memberA;
  int memberB;
} MyExportedTypeStruct;
typedef MyExportedTypeStruct *MyExportedType; /**< type definition */

/** \var MyExportedTypeStruct::memberA
        lots of documentation here 
        lots of documentation here 
        lots of documentation here 
        lots of documentation here 
        lots of documentation here
*//** \var MyExportedTypeStruct::memberB
        lots of documentation here 
        lots of documentation here 
        lots of documentation here 
        lots of documentation here 
        lots of documentation here
*/

/** @} */

(c) And here's how I'd like to document things:

/**
  @addtogroup MyGroup
  @{ 
*/

/**
  short descriptionof MyExportedTypeStruct.
  long description.
  \var memberA
        lots of documentation here 
        lots of documentation here 
        lots of documentation here 
        lots of documentation here 
        lots of documentation here
  \var memberB
        lots of documentation here 
        lots of documentation here 
        lots of documentation here 
        lots of documentation here 
        lots of documentation here
*/
typedef struct {
  int memberA;
  int memberB;
} MyExportedTypeStruct;
typedef MyExportedTypeStruct *MyExportedType; /**< type definition */

/** @} */


	Micha.

-- 
-- Michael Daum
-- Natural Language Systems
-- Faculty of Informatics
---University of Hamburg
-- http://nats-www.informatik.uni-hamburg.de/~micha

Re: [Doxygen-develop] documenting c-struct members

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

On Fri, Sep 26, 2003 at 12:32:52PM +0200, Michael Daum wrote:
> Hi everybody,
> 
> here's a thread that I started on doxygen-users. Maybe I get an answer 
> to my questions below on doxygen-develop, hopefully.
> 
> 	Micha.
> 
> On Monday 22 September 2003 23:01, Dimitri van Heesch wrote:
> > On Mon, Sep 22, 2003 at 09:19:18AM +0200, Michael Daum wrote:
> > > is it possible to document c-struct members at another place? 
> > Probably the following:
> >
> > struct c_struct
> > {
> >   int field1;
> >   int field2;
> > };
> >
> > /*! \struct c_struct
> >     My struct
> >  */
> >
> > /*! \var c_struct::field1
> >     First field
> >  */
> >
> > /*! \var c_struct::field2
> >     Second field
> >  */
> >
> 
> Ah. 
> 
> But I don't get exactly what I wanted. The c_struct is part of a group 
> (of related structures). The \var docu then goes into the group docu
> (section Variables) and is marked 'inherited'. Actually I expected the 
> c_struct::field1 to be on the page documenting the c_struct. 

Me too. Are you sure only the c_struct is grouped? Or is the whole struct
with everything in it grouped? This probably depends on whether @ingroup 
is used (good) or if the whole struct is in a @defgroup .. @{  ... @} 
block (bad in this case). Please provide an example to make it easier to
discuss about the problem.

Regards,
  Dimitri

Re: [Doxygen-develop] Subdirectory = module

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

On Wed, Sep 24, 2003 at 03:43:01PM -0700, Robin Rowe wrote:
> Dimitri,
> 
> > GTK 1.4 was probably not documented using doxygen commands. So no wonder
> that
> > the results may be unexpected.
> 
> True, but does that answer my question? If you don't know why, can you point
> me to the documentation for doxygen modules so I can figure out why doxygen
> is reporting printf as a module?

Modules are defined by grouping things: see
http://www.stack.nl/~dimitri/doxygen/grouping.html
for more info. If printf is in a module there is probably a \defgroup or
related command somewhere in the neighbourhood.

> > Doxygen does not yet have an option to
> > turn directories automatically into modules, but this is on the todo list.
> 
> Ah, a developer question after all! ;-) Who is the developer assigned for
> that task or are you looking for help?

No one's assigned yet, so I can use the help or else I'll probably
end up adding it myself some day.

Regards,
  Dimitri

[Doxygen-develop] documenting c-struct members

[Michael D. <mi...@na...>]

Hi everybody,

here's a thread that I started on doxygen-users. Maybe I get an answer 
to my questions below on doxygen-develop, hopefully.

	Micha.

On Monday 22 September 2003 23:01, Dimitri van Heesch wrote:
> On Mon, Sep 22, 2003 at 09:19:18AM +0200, Michael Daum wrote:
> > is it possible to document c-struct members at another place? 
> Probably the following:
>
> struct c_struct
> {
>   int field1;
>   int field2;
> };
>
> /*! \struct c_struct
>     My struct
>  */
>
> /*! \var c_struct::field1
>     First field
>  */
>
> /*! \var c_struct::field2
>     Second field
>  */
>

Ah. 

But I don't get exactly what I wanted. The c_struct is part of a group 
(of related structures). The \var docu then goes into the group docu
(section Variables) and is marked 'inherited'. Actually I expected the 
c_struct::field1 to be on the page documenting the c_struct. 
Putting together all variables of all c-structures of a group is not a very good idea.

Another thing is that each \var needs a document block of its own. So here's 
one for the wishlist: 
  (1) make consecutive s work in one document block:

    /** \var c_struct::field1
     *        First Field.
     * \var c_struct::field2
     *        Second Field.
     */

  (2) make c_struct:: in c_struct::field1 dispensable in the document block belonging
    to that structure

    /** A structure description.
     * \var field1
     *       First Field.
     * \var field2
     *       Second Field
     */
    struct c_struct {
        field1;
        field2;
    };

Difficult?

Micha.

-- 
-- Michael Daum
-- Natural Language Systems
-- Faculty of Informatics
---University of Hamburg
-- http://nats-www.informatik.uni-hamburg.de/~micha

Re: [Doxygen-develop] Subdirectory = module

[Robin R. <ro...@Mo...>]

Dimitri,

> GTK 1.4 was probably not documented using doxygen commands. So no wonder
that
> the results may be unexpected.

True, but does that answer my question? If you don't know why, can you point
me to the documentation for doxygen modules so I can figure out why doxygen
is reporting printf as a module?

> Doxygen does not yet have an option to
> turn directories automatically into modules, but this is on the todo list.

Ah, a developer question after all! ;-) Who is the developer assigned for
that task or are you looking for help?

Thanks,

Robin
---------------------------------------------------------------------------
Rob...@Mo...   Hollywood, California
www.CinePaint.org   Free motion picture and still image editing software