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

[Doxygen-develop] Upgrading from 1.4.7 to 1.5.6: need answers

[Jason M. <ko...@gm...>]

OK, so I've been holding off on updating Doxygen because I couldn't 
build the new versions (VC 7.1 was not supported in 1.5.0 and greater 
builds). Since then, I've upgraded to VC9, so I can build again. 
However, I have written a new export format, and a lot of Doxygen's 
internals have changed. I'm trying to find the new way to do the things 
that used to work. Here's the list of questions:

1: MemberDef::hasUserDocumentation() seems to occasionally return true 
for elements that don't actually have documentation. That is, the 
MemberDef::briefDescription() and MemberDef::documentation() are empty. 
Is there a function that will test whether a function actually has 
documentation in these strings, or do I have to fetch them and test to 
see if they are "empty"? I would like a function that returns "true" if 
and only if the user put brief documentation or long documentation.

2: This is something of a long-running issue that I had in the first 
one, but my old workarounds don't work. I have a Definition of some kind 
(I can get the actual type if needs be). And that Definition has some 
number of MemberLists in it. My format doesn't separate the contents of 
a MemberList into the same groupings that Doxygen likes (public, 
private, types, etc). All it wants is a list of user-defined MemberLists 
(groups that the user explicitly created with @name and @{ @} blocks) 
and every other member of the Definition that is NOT in a user-defined 
group. I'm building my own lists of members, so I don't need Doxygen to 
have its MemberList internal structures changed. The user-defined 
MemberLists are easy to find. The problem is that my old workaround to 
get the members that aren't in a user-defined group doesn't work 
anymore. I'm fine with iterating over all the MemberLists in a 
Definition, but I need some way to build a sequence of Definition 
members of a Definition that are not in a user-defined group.

Any ideas?

Re: [Doxygen-develop] Support for PHP namespaces

[Karsten D. <ka...@ty...>]

Hi Dimitri,

thanks for the quick response!

On 16.09.2008, at 20:36, Dimitri Van Heesch wrote:
> I suggest to file a bug report with severity set to enhancement  
> about this feature request and
> include some (references to) examples of typically usages (and/or a  
> link to a formal grammar).

I'll do so.

> From what I seen so far, it should basically be enough if doxygen  
> treats
> "namespace X::Y::Z;", as if "namespace X { namespace Y { namespace Z  
> {" had been written in C#/C++ (where the
> closing }'s are all at the end of the file. Is this correct?


That should be ok, yes. It might be that the PHP core developers  
change namespace handling slightly to make it block-level, so that we  
could have "namespace X::Y::Z { ... }" and a possible nesting. That  
would be a "mixture of both worlds" so to speak.

Regards,
Karsten
-- 
Karsten Dambekalns
Gimme Five!
http://typo3.org/gimmefive

Re: [Doxygen-develop] Support for PHP namespaces

[Dimitri V. H. <do...@gm...>]

On 16 sep 2008, at 11:28, Karsten Dambekalns wrote:

> Hi.
>
> We are currently looking into using Doxygen for FLOW3/TYPO3v5 after  
> having switched to using PHP namespaces. Currently we use  
> phpDocumentor, but it seems to be inactive so support for namespaces  
> might never come...
>
> A first try with Doxygen looks promising, but one thing that is a  
> showstopper is missing support for PHP namespaces. Admittedly it is  
> not yet fully clear whether PHP will use
> namespace X::Y::Z;
> or rather
> namespace X::Y::Z { ..: }
> but this is about everything that remains to be seen.
>
> I ran Doxygen in our codebase, and it detects "some" namespace, but  
> e.g. the class hierarchy is completely flat.
>
> What would be the best way of getting Doxygen nearer to what we need  
> given that I have never coded C? Who is maintaining the PHP support  
> of Doxygen?

I'm maintaining everything related to Doxygen, so also PHP support ;-)

I suggest to file a bug report with severity set to enhancement about  
this feature request and
include some (references to) examples of typically usages (and/or a  
link to a formal grammar).

 From what I seen so far, it should basically be enough if doxygen  
treats
"namespace X::Y::Z;", as if "namespace X { namespace Y { namespace Z  
{" had been written in C#/C++ (where the
closing }'s are all at the end of the file. Is this correct?

Regards,
   Dimitri

[Doxygen-develop] Support for PHP namespaces

[Karsten D. <ka...@ty...>]

Hi.

We are currently looking into using Doxygen for FLOW3/TYPO3v5 after  
having switched to using PHP namespaces. Currently we use  
phpDocumentor, but it seems to be inactive so support for namespaces  
might never come...

A first try with Doxygen looks promising, but one thing that is a  
showstopper is missing support for PHP namespaces. Admittedly it is  
not yet fully clear whether PHP will use
  namespace X::Y::Z;
or rather
  namespace X::Y::Z { ..: }
but this is about everything that remains to be seen.

I ran Doxygen in our codebase, and it detects "some" namespace, but  
e.g. the class hierarchy is completely flat.

What would be the best way of getting Doxygen nearer to what we need  
given that I have never coded C? Who is maintaining the PHP support of  
Doxygen?

Regards,
Karsten
-- 
Karsten Dambekalns
Gimme Five!
http://typo3.org/gimmefive

Re: [Doxygen-develop] @ingroup tag for pages

[<Eck...@t-...>]

Hello Mr Kimmerstorfer.

I'm missing also this inpage-command. But I've found an possibility to
simulate this.


Try the following:


/**
@page page_1 Page 1



First Part-Content of page 1

...
*/

/**

@page page_1 Page 1

@subpage page_1_1 

@page page_1_1 Page 1.1


Content of page 1.1

...
*/



**

@page page_1 Page 1

@subpage page_1_2 

@page page_1_2 Page 1.2


Content of page 1.2

...
*/



Using the page-command more than once for the same page has not the
effect that the result of the first commands will be overwritten. It has
the effect that the new content will be added to the old.  If you only
use the subpage-command between the page-command of the containig page
and the page-commang of the contained page only the refference to the
contained page will be added to the containing page. The order of the
part-contents of the containing page depends on the order of the
commmands doxygen will find.

Perhaps it may be a good idea to use an alias to create an inpage
command 
 

I hope this will help you.

Best regards,
                          Eckard Klotz





-----Original Message-----
Date: Thu, 11 Sep 2008 09:33:37 +0200
Subject: [Doxygen-develop]  @ingroup tag for pages
From: <Eug...@CO...>
To: <do...@gm...>, <dox...@li...>,
<jan...@co...>

dear doxygen users and developers,

for structuring modules in doxygen, you can use e.g. the @defgroup and
@ingroup tags to define a hierarchie. this works "bottom up", meaning
that in a @defgroup block, an @ingroup tag defines the parent module.

is there something similar for pages?

for pages, you can define a structure only "top down".

example:

/**
@page page_1 Page 1

...
@subpage page_1_1
*/

/**
@page page_1_1 Page 1.1
...
*/

what we would need for our purpose is something like at "@inpage" tag:

/**
@page page_1 Page 1
...
*/

/**
@page page_1_1 Page 1.1
@inpage page_1
...
*/

would this make sense to include into a future release?

best regards,
Eugen

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Doxygen-develop mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] @ingroup tag for pages

[<Eug...@CO...>]

dear doxygen users and developers,

for structuring modules in doxygen, you can use e.g. the @defgroup and @ingroup tags to define a hierarchie. this works "bottom up", meaning that in a @defgroup block, an @ingroup tag defines the parent module.

is there something similar for pages?

for pages, you can define a structure only "top down".

example:

/**
@page page_1 Page 1

...
@subpage page_1_1
*/

/**
@page page_1_1 Page 1.1
...
*/

what we would need for our purpose is something like at "@inpage" tag:

/**
@page page_1 Page 1
...
*/

/**
@page page_1_1 Page 1.1
@inpage page_1
...
*/

would this make sense to include into a future release?

best regards,
Eugen

Re: [Doxygen-develop] Problems generating LaTeX output with Doxygen v1.5.6

[<Mar...@co...>]

Hi Dimitri,

Is it possible that there are still some open issues concerning this problem?

It seems that the generated latex (pdf) structure of content is different to the generated html (chm) content.
We are using the tags @page, @subpage, @section, @mainpage in our external documents, and the structure and order of the singular sections differs from the chm to the pdf, whereas the pdf output looks very damaged.

Thanks in advance,
Marc

-----Original Message-----
From: Dimitri Van Heesch [mailto:do...@gm...]
Sent: Friday, September 05, 2008 7:12 PM
To: Kurz Marc (CNAT SWL SEG)
Cc: dox...@li...; jan...@co...
Subject: Re: [Doxygen-develop] Problems generating LaTeX output with Doxygen v1.5.6


Hi Marc,

There were some issues with handling pages in the LaTeX output (in particular the use of @subpage inside @mainpage) with version 1.5.6. These should be resolved in the latest snapshot found in subversion.
So please try that if possible and let me know if you still see problems.

Regards,
   Dimitri

On 5 sep 2008, at 08:14, <Mar...@co...> <Mar...@co...> wrote:

>  Hi,
>
> I will try to explain my problem more detailed. Firstly, to avoid
> misunderstandings I have to clarify a few things:
>
> -> LaTeX processing (the generation of the pdf file out of the LaTeX
> sources) does NOT show errors, so the LaTeX Syntax is correct.
> -> CHM generation works without (semantic and syntactic) problems.
> -> Some informtaion is just missing in the LaTeX output, that means:
>         - On the one side we have the C/C++ header files, they contain
> the doxygen comments
>         - On the other side we have some (external) files, they are
> included to the doxygen generation via the INPUT tag.
>         - Those files contain also doxygen commands, here is a small
> example for such a file:
>
>
>          /**
>         @page my_id Detailed Interface Specification
>
>         Here is a list of the modules which are relevant for the
> Interface:
>         <ul>
>           <li>Module (@ref ID_OF_MODULE)</li>
>         </ul>
>      */
>
>         When we generated the documentation with doxygen 1.5.5, both
> the chm and pdf generation worked without problems, but since we are
> using the new version 1.5.6, the chm generation still works, but the
> pdf generation fails. Those external files are not included in the
> LaTeX sources (so doxygen somehow overlooks them I guess)...
>
>
> Thanks,
>
> Marc
>
>
>
> -----Original Message-----
> From: Jan Ruzicka [mailto:jan...@co...]
> Sent: Wednesday, September 03, 2008 4:32 PM
> To: Kurz Marc (CNAT SWL SEG)
> Subject: Re: [Doxygen-develop] Problems generating LaTeX output with
> Doxygen v1.5.6
>
> Hi Marc
>
> Can you be more specific about the issue with LaTeX?
> From your description I'm not sure what do you consider a problem.
> Is LaTeX output missing some information present in HTML version?
> Is LaTeX processing showing some error messages?
> Please send the clarification to list as I may not be able to help
> you, but it sounds as interesting problem.
> I'm sending this e-mail to you as I don't want to pollute the list.
>
> Thanks
> Jan
>
> On 2008/09/03 06:34AM, "Mar...@co..." <Mar...@co...>
> wrote:
>
> > Dear Doxygen Users and Developers,
> >
> > We are using Doxygen for generating html (chm) and latex (pdf)
> > documentation out of our C/C++ source Code.
> > Along with the header files that contain the doxygen-comments, some
> > additional *.html files are included in the process of generating
> doxygen documentation.
> > Those extra-html files contain things like Introduction, Examples of
> > Use, Revision History, etc.. They contain doxygen commands like e.g.
> > (and are of course doxygen-conform):
> > *       @mainpage
> > *       @section
> > *       @subpage
> > *       ...
> >
> > The generated doxygen html- and latex-output is processed by a
> > self-written perl script to meet our standards in form and content.
> >
> > Generating the html (chm) output works very fine, no problems
> occur at all.
> > However, since we are using the new version 1.5.6 of doxygen, those
> > extra *.html files are ignored by the doxygen process when
> generating
> > latex output (html still works without problems).
> >
> > Is this a possible bug in the new version, or are we just
> overlooking
> > something?
> >
> > Thanks in advance,
> > Best Regards,
> > Marc
> >

[Doxygen-develop] Expand 'Include Dependency Graphs' automatically

[Sylvain J. <syl...@gm...>]

Hello,

How can I have the dependency graphs automatically show up in my HTML pages?
Currently I need to click on the link 'Include dependency graph for ...' to
see the graph image.

I posted this question to doxygen-users, but got no answer there. Sorry for
the double posting.
Thank you for any hint!
Sylvain

Re: [Doxygen-develop] Problems generating LaTeX output with Doxygen v1.5.6

[<Mar...@co...>]

Hi Dimitri,

Thanks for the info, this works. No further problems occur.

BR,
Marc

-----Original Message-----
From: Dimitri Van Heesch [mailto:do...@gm...]
Sent: Friday, September 05, 2008 7:12 PM
To: Kurz Marc (CNAT SWL SEG)
Cc: dox...@li...; jan...@co...
Subject: Re: [Doxygen-develop] Problems generating LaTeX output with Doxygen v1.5.6


Hi Marc,

There were some issues with handling pages in the LaTeX output (in particular the use of @subpage inside @mainpage) with version 1.5.6. These should be resolved in the latest snapshot found in subversion.
So please try that if possible and let me know if you still see problems.

Regards,
   Dimitri

On 5 sep 2008, at 08:14, <Mar...@co...> <Mar...@co...> wrote:

>  Hi,
>
> I will try to explain my problem more detailed. Firstly, to avoid
> misunderstandings I have to clarify a few things:
>
> -> LaTeX processing (the generation of the pdf file out of the LaTeX
> sources) does NOT show errors, so the LaTeX Syntax is correct.
> -> CHM generation works without (semantic and syntactic) problems.
> -> Some informtaion is just missing in the LaTeX output, that means:
>         - On the one side we have the C/C++ header files, they contain
> the doxygen comments
>         - On the other side we have some (external) files, they are
> included to the doxygen generation via the INPUT tag.
>         - Those files contain also doxygen commands, here is a small
> example for such a file:
>
>
>          /**
>         @page my_id Detailed Interface Specification
>
>         Here is a list of the modules which are relevant for the
> Interface:
>         <ul>
>           <li>Module (@ref ID_OF_MODULE)</li>
>         </ul>
>      */
>
>         When we generated the documentation with doxygen 1.5.5, both
> the chm and pdf generation worked without problems, but since we are
> using the new version 1.5.6, the chm generation still works, but the
> pdf generation fails. Those external files are not included in the
> LaTeX sources (so doxygen somehow overlooks them I guess)...
>
>
> Thanks,
>
> Marc
>
>
>
> -----Original Message-----
> From: Jan Ruzicka [mailto:jan...@co...]
> Sent: Wednesday, September 03, 2008 4:32 PM
> To: Kurz Marc (CNAT SWL SEG)
> Subject: Re: [Doxygen-develop] Problems generating LaTeX output with
> Doxygen v1.5.6
>
> Hi Marc
>
> Can you be more specific about the issue with LaTeX?
> From your description I'm not sure what do you consider a problem.
> Is LaTeX output missing some information present in HTML version?
> Is LaTeX processing showing some error messages?
> Please send the clarification to list as I may not be able to help
> you, but it sounds as interesting problem.
> I'm sending this e-mail to you as I don't want to pollute the list.
>
> Thanks
> Jan
>
> On 2008/09/03 06:34AM, "Mar...@co..." <Mar...@co...>
> wrote:
>
> > Dear Doxygen Users and Developers,
> >
> > We are using Doxygen for generating html (chm) and latex (pdf)
> > documentation out of our C/C++ source Code.
> > Along with the header files that contain the doxygen-comments, some
> > additional *.html files are included in the process of generating
> doxygen documentation.
> > Those extra-html files contain things like Introduction, Examples of
> > Use, Revision History, etc.. They contain doxygen commands like e.g.
> > (and are of course doxygen-conform):
> > *       @mainpage
> > *       @section
> > *       @subpage
> > *       ...
> >
> > The generated doxygen html- and latex-output is processed by a
> > self-written perl script to meet our standards in form and content.
> >
> > Generating the html (chm) output works very fine, no problems
> occur at all.
> > However, since we are using the new version 1.5.6 of doxygen, those
> > extra *.html files are ignored by the doxygen process when
> generating
> > latex output (html still works without problems).
> >
> > Is this a possible bug in the new version, or are we just
> overlooking
> > something?
> >
> > Thanks in advance,
> > Best Regards,
> > Marc
> >

Re: [Doxygen-develop] Problems generating LaTeX output with Doxygen v1.5.6

[Dimitri V. H. <do...@gm...>]

Hi Marc,

There were some issues with handling pages in the LaTeX output (in  
particular the use of @subpage inside @mainpage)
with version 1.5.6. These should be resolved in the latest snapshot  
found in subversion.
So please try that if possible and let me know if you still see  
problems.

Regards,
   Dimitri

On 5 sep 2008, at 08:14, <Mar...@co...>  
<Mar...@co...> wrote:

>  Hi,
>
> I will try to explain my problem more detailed. Firstly, to avoid  
> misunderstandings I have to clarify a few things:
>
> -> LaTeX processing (the generation of the pdf file out of the LaTeX  
> sources) does NOT show errors, so the LaTeX Syntax is correct.
> -> CHM generation works without (semantic and syntactic) problems.
> -> Some informtaion is just missing in the LaTeX output, that means:
>         - On the one side we have the C/C++ header files, they  
> contain the doxygen comments
>         - On the other side we have some (external) files, they are  
> included to the doxygen generation via the INPUT tag.
>         - Those files contain also doxygen commands, here is a small  
> example for such a file:
>
>
>          /**
>         @page my_id Detailed Interface Specification
>
>         Here is a list of the modules which are relevant for the  
> Interface:
>         <ul>
>           <li>Module (@ref ID_OF_MODULE)</li>
>         </ul>
>      */
>
>         When we generated the documentation with doxygen 1.5.5, both  
> the chm and pdf generation worked without problems, but since we are  
> using the new version 1.5.6, the chm generation still works, but the  
> pdf generation fails. Those external files are not included in the  
> LaTeX sources (so doxygen somehow overlooks them I guess)...
>
>
> Thanks,
>
> Marc
>
>
>
> -----Original Message-----
> From: Jan Ruzicka [mailto:jan...@co...]
> Sent: Wednesday, September 03, 2008 4:32 PM
> To: Kurz Marc (CNAT SWL SEG)
> Subject: Re: [Doxygen-develop] Problems generating LaTeX output with  
> Doxygen v1.5.6
>
> Hi Marc
>
> Can you be more specific about the issue with LaTeX?
> From your description I'm not sure what do you consider a problem.
> Is LaTeX output missing some information present in HTML version?
> Is LaTeX processing showing some error messages?
> Please send the clarification to list as I may not be able to help  
> you, but it sounds as interesting problem.
> I'm sending this e-mail to you as I don't want to pollute the list.
>
> Thanks
> Jan
>
> On 2008/09/03 06:34AM, "Mar...@co..." <Mar...@co...>
> wrote:
>
> > Dear Doxygen Users and Developers,
> >
> > We are using Doxygen for generating html (chm) and latex (pdf)
> > documentation out of our C/C++ source Code.
> > Along with the header files that contain the doxygen-comments, some
> > additional *.html files are included in the process of generating  
> doxygen documentation.
> > Those extra-html files contain things like Introduction, Examples of
> > Use, Revision History, etc.. They contain doxygen commands like e.g.
> > (and are of course doxygen-conform):
> > *       @mainpage
> > *       @section
> > *       @subpage
> > *       ...
> >
> > The generated doxygen html- and latex-output is processed by a
> > self-written perl script to meet our standards in form and content.
> >
> > Generating the html (chm) output works very fine, no problems  
> occur at all.
> > However, since we are using the new version 1.5.6 of doxygen, those
> > extra *.html files are ignored by the doxygen process when  
> generating
> > latex output (html still works without problems).
> >
> > Is this a possible bug in the new version, or are we just  
> overlooking
> > something?
> >
> > Thanks in advance,
> > Best Regards,
> > Marc
> >

Re: [Doxygen-develop] Problems generating LaTeX output with Doxygen v1.5.6

[<Mar...@co...>]

 Hi,

I will try to explain my problem more detailed. Firstly, to avoid misunderstandings I have to clarify a few things:

-> LaTeX processing (the generation of the pdf file out of the LaTeX sources) does NOT show errors, so the LaTeX Syntax is correct.
-> CHM generation works without (semantic and syntactic) problems.
-> Some informtaion is just missing in the LaTeX output, that means:
        - On the one side we have the C/C++ header files, they contain the doxygen comments
        - On the other side we have some (external) files, they are included to the doxygen generation via the INPUT tag.
        - Those files contain also doxygen commands, here is a small example for such a file:

         /**
        @page my_id Detailed Interface Specification

        Here is a list of the modules which are relevant for the Interface:
        <ul>
          <li>Module (@ref ID_OF_MODULE)</li>
        </ul>
     */

        When we generated the documentation with doxygen 1.5.5, both the chm and pdf generation worked without problems, but since we are using the new version 1.5.6, the chm generation still works, but the pdf generation fails. Those external files are not included in the LaTeX sources (so doxygen somehow overlooks them I guess)...



Thanks,

Marc



-----Original Message-----
From: Jan Ruzicka [mailto:jan...@co...]
Sent: Wednesday, September 03, 2008 4:32 PM
To: Kurz Marc (CNAT SWL SEG)
Subject: Re: [Doxygen-develop] Problems generating LaTeX output with Doxygen v1.5.6

Hi Marc

Can you be more specific about the issue with LaTeX?
>From your description I'm not sure what do you consider a problem.
Is LaTeX output missing some information present in HTML version?
Is LaTeX processing showing some error messages?
Please send the clarification to list as I may not be able to help you, but it sounds as interesting problem.
I'm sending this e-mail to you as I don't want to pollute the list.

Thanks
Jan

On 2008/09/03 06:34AM, "Mar...@co..." <Mar...@co...>
wrote:

> Dear Doxygen Users and Developers,
>
> We are using Doxygen for generating html (chm) and latex (pdf)
> documentation out of our C/C++ source Code.
> Along with the header files that contain the doxygen-comments, some
> additional *.html files are included in the process of generating doxygen documentation.
> Those extra-html files contain things like Introduction, Examples of
> Use, Revision History, etc.. They contain doxygen commands like e.g.
> (and are of course doxygen-conform):
> *       @mainpage
> *       @section
> *       @subpage
> *       ...
>
> The generated doxygen html- and latex-output is processed by a
> self-written perl script to meet our standards in form and content.
>
> Generating the html (chm) output works very fine, no problems occur at all.
> However, since we are using the new version 1.5.6 of doxygen, those
> extra *.html files are ignored by the doxygen process when generating
> latex output (html still works without problems).
>
> Is this a possible bug in the new version, or are we just overlooking
> something?
>
> Thanks in advance,
> Best Regards,
> Marc
>
> ___________________________________________
>
> Marc Kurz Bakk.techn.
> Customer Support, Documentation Management Assistant
>
> COMNEON electronic technology GmbH & Co. OHG Freistaedter Strasse 400
> A-4040 Linz, Austria
>
> Tel.: +43 (5) 1777 15 - 604
> Fax: +43 (5) 1777 15 - 810
> E-Mail: mailto:mar...@co...
> WEB: http://www.comneon.com
>
> COMNEON - Great Ideas for Small Devices
> ___________________________________________
>
>
>
> ----------------------------------------------------------------------
> --- This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK &
> win great prizes Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

--
Jan Ruzicka
Software Engineer
jan...@co...
Phone: 240-686-3364

Comtech Mobile Datacom Corp.
20430 Century Boulevard
Germantown, MD 20874
Phone: 240-686-2100
Fax: 240-686-3301

This email and any attachments are intended exclusively for the individuals or entities to which it is addressed. This communication may contain information that is proprietary, privileged or confidential, or otherwise legally exempt from disclosure. If you are not a named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message, any attachments, and any copies thereof from your system.

[Doxygen-develop] Problems generating LaTeX output with Doxygen v1.5.6

[<Mar...@co...>]

Dear Doxygen Users and Developers,

We are using Doxygen for generating html (chm) and latex (pdf) documentation out of our C/C++ source Code.
Along with the header files that contain the doxygen-comments, some additional *.html files are included in the process of generating doxygen documentation. Those extra-html files contain things like Introduction, Examples of Use, Revision History, etc.. They contain doxygen commands like e.g. (and are of course doxygen-conform):
*       @mainpage
*       @section
*       @subpage
*       ...

The generated doxygen html- and latex-output is processed by a self-written perl script to meet our standards in form and content.

Generating the html (chm) output works very fine, no problems occur at all.
However, since we are using the new version 1.5.6 of doxygen, those extra *.html files are ignored by the doxygen process when generating latex output (html still works without problems).

Is this a possible bug in the new version, or are we just overlooking something?

Thanks in advance,
Best Regards,
Marc

___________________________________________

Marc Kurz Bakk.techn.
Customer Support, Documentation Management Assistant

COMNEON electronic technology GmbH & Co. OHG
Freistaedter Strasse 400
A-4040 Linz, Austria

Tel.: +43 (5) 1777 15 - 604
Fax: +43 (5) 1777 15 - 810
E-Mail: mailto:mar...@co...
WEB: http://www.comneon.com

COMNEON - Great Ideas for Small Devices
___________________________________________

Re: [Doxygen-develop] Feature Request: A small change would makedoxygen fit for incremental SVN updates

[Thomas T. <dox...@th...>]

Great, that worked! Thanks so much, Thomas

Erik Zeek wrote:
>
> Perhaps your looking for HTML_HEADER and HTML_FOOTER?
> http://www.stack.nl/~dimitri/doxygen/config.html#cfg_html_header 
> <http://www.stack.nl/%7Edimitri/doxygen/config.html#cfg_html_header>
>
> Erik
>

Re: [Doxygen-develop] Feature Request: A small change would make doxygen fit for incremental SVN updates

[Erik Z. <ze...@ma...>]

On Friday 29 August 2008, Thomas T. wrote:
> Hello,
>
> We are using doxygen quite successfully in our project, thanks for a
> great tool!
>
> I have a little feature request that could probably be implemented
> almost instantly. We need to store the doxygen HTML output in a
> Subversion repository, since users do not want to create the
> documentation for themselves and we distribute the code via SVN, so we
> check the HTML files produced by doxygen into the SVN repository. I know
> SVN is not a conventional place to put documentation, but in our project
> it is the only convenient way to keep it updated.
>
> However, doxygen even for unchanged pages produces new files that are
> not identical in content (mainly the footer), so each time the
> documentation needs to be reproduced, the whole documentation is
> uploaded to the SVN server. So my request is to make an option to
> disable these "Generated on <date> <tim> for <project> by <doxygen
> version>" footers from the files so they do no longer differ in content
> and Subversion will recognize them as same.
>
> That would really be a relief!
>
> Thanks,
> Thomas

Perhaps your looking for HTML_HEADER and HTML_FOOTER?
http://www.stack.nl/~dimitri/doxygen/config.html#cfg_html_header

Erik

-- 
*******************************************
Erik Zeek
Email: mailto:ze...@ma...
Html:  http://www.physast.uga.edu/~zeekec
*******************************************
Against stupidity the very gods
Themselves contend in vain.
 - Johann Christoph Friedrich von Schiller (1801)
*******************************************

Re: [Doxygen-develop] Feature Request: A small change would make doxygen fit for incremental SVN updates

[Andrew F. <pb...@gm...>]

I second the request.  I have a nightly job that regenerates the
documentation for a pretty big tool, it takes the better part of 4-6 hours
when done from scratch.  I would check-in the files to our perforce depot to
make them available via p4web, if they didn't generate gabillions of changed
files "for no reason".

--andy


On Fri, Aug 29, 2008 at 11:02 PM, Thomas T. <
dox...@th...> wrote:

> So my request is to make an option to
> disable these "Generated on <date> <tim> for <project> by <doxygen
> version>" footers from the files so they do no longer differ in content
> and Subversion will recognize them as same.
>

[Doxygen-develop] Feature Request: A small change would make doxygen fit for incremental SVN updates

[Thomas T. <dox...@th...>]

Hello,

We are using doxygen quite successfully in our project, thanks for a 
great tool!

I have a little feature request that could probably be implemented 
almost instantly. We need to store the doxygen HTML output in a 
Subversion repository, since users do not want to create the 
documentation for themselves and we distribute the code via SVN, so we 
check the HTML files produced by doxygen into the SVN repository. I know 
SVN is not a conventional place to put documentation, but in our project 
it is the only convenient way to keep it updated.

However, doxygen even for unchanged pages produces new files that are 
not identical in content (mainly the footer), so each time the 
documentation needs to be reproduced, the whole documentation is 
uploaded to the SVN server. So my request is to make an option to 
disable these "Generated on <date> <tim> for <project> by <doxygen 
version>" footers from the files so they do no longer differ in content 
and Subversion will recognize them as same.

That would really be a relief!

Thanks,
Thomas

[Doxygen-develop] TO-DO item 10 and suggestions for @import/@region/@endregion

[Dan L. <dl...@he...>]

Dear List:

Citation of TO-DO list item 10 regarding proposed
@import/@region/@endregion command suite followed by my suggestions:

---------------
Requested by Erik Johannes: 
The ability to include a block of text from a file. This should not
always be all the contents of the file, but instead a specific region
from the file. 

Suggested are the following tags: 

    @import <file> [region-tag]

Imports the contents of the file in to the current stream of processing.
The imported text is treated as if it had been located at the site of
importation. If the optional [region-tag] is specified, then only those
regions in the file being imported that have the specified [region-tag]
will be imported.
All other contents of the imported file will be ignored. 

    @region <region-tag> [skip-lines]

Specifies the beginning of a region that can be imported into the
processing stream of another file using the import command. The
importation will begin at the line following the line the region command
is found on. The optional [skip-lines] parameter can be used to specify
that the next n lines following the line containing the region command
should not be imported. Importation will continue until an endregion for
the specified tag is found or the end of file is reached.

The importation is verbatim with the exception of an other embedded
region/endregion lines within the region block being imported. Those
embedded region/endregion lines will be excluded from the importation. 

    @endregion <region-tag>

Ends the current named region specified by the tag. 

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

My comments:

I was introduced about 5 years ago to Doxygen and have used it in a
number of projects.  I am currently involved in one which could make
effective use of the @import/@region/@endregion commands as suggested
above.

What would it take to implement the suite of @import/@region/@endregion
keywords?  What area of the code need modification?  I am currently
examining the 1.5.6 source code and see the lexeme parsing in
'src/scanner.l' but there appears to be quite a number of intergrated
components that support specific language parsers as well.  Would this
feature be only concerned with 'src/scanner.l' or would there be
additional areas needing modification?  It appeared on first glance like
the following files also might
participate:

    doc/commands.doc

    src/cmdmapper.cpp
    src/commentscan.l
    src/compound.xsd
    src/compound_xsd.h
    src/docparser.{cpp|h"
    src/docparser.{cpp|h}
    src/{html|latex|man|rtfdoc|xml}visitor.{cpp|h}

    addon/doxmlparser/include/doxmlintf.h
    addon/doxmlparser/src/dochandler.{cpp|h}
    addon/doxmlparser/src/doxmlintf.h
    addon/doxmlparser/test/main.cpp

I am sure this is only a partial an probably inaccurate list.

If I were to use these keywords, I would suggest that a list of regions
be specified, so instead of @e only an optional @e single region tag to
be imported,

    @import <file> [region_tag]

I might suggest a list of them,

    @import <file> [region_tag1 [, region_tag2...]]

suggesting commas as a delimter only since I am not @e intimately
familiar with the nuances of all Doxygen particulars.  (Perhaps white
space alone would be enough?)  However, a series of @import lines could
work just fine as well,

    @import <file> region_tag1
    @import <file> region_tag2
    ...

I think the exclusion of embedded @region and @endregion tags embedded
within a @region/@endregion pair is the right thing to do.  Also, I
would assume that any embedded @import statements would be processed
like any other tag?

Another possibility for something that is @e similar to
@import/@region/@endregion might be to modify the @copydoc tag, which
currently is defined as,

    @copydoc <link-object>

Perhaps two modifications to this
tag would be useful.  The first would
perform something similar to the
TO-DO item 10 using @import/@region/@endregion but might be simpler to
implement since it would use @e only existing structures:

    @copydoc <link-object> [section-name-1 [, section-name-2 [...]]

This would perform an @import of one or more named sections.  A related
idea might be to use this syntax to import one or more named sections or
pages instead, this time using the same idea as @copybrief and
@copydetails (BTW, the @copydoc reference to those items say
"\cmdcopybrief" and "\cmdcopydetails"
instead of "\copybrief" and "\copydetails", respectively).
These might look like,

    @copysection section-name-1 [, section-name-2 [...]]

    @copypage page-name-1 [, page-name-2 [...]]

Would these ideas help perform a simpler @import at the expense of being
less generic?  I think they might work because if text is already
organized into @page and @section logically, perhaps this might fill in
much of a completely generic @import.

<b>ON THE OTHER HAND</b>, an @import/@region/@endregion suite of
commands is @e not bound to any particular of @page or @section
organization.  It might be a second step in implementing a @copyXXX
modification above.  It also might be considered more generic to have a
"label"
for a sub-region as well as or perhaps instead of a "skip-lines" value:

    @region <region-tag> [skip-lines]

might be extended/replaced by:

    @region <region-tag> [region-label]
    ...
    @regionlabel abc
    ...
    @endregion [region-tag]

Where 'abc' is the optional 'region-label'.

Honestly, though, I think that a simple,

    @region <region-tag>
    ...
    @endregion <region-tag>

should be enough without either a 'skip-lines' or 'region-label'
modifier.  If I wanted some offset, why not simply have a different
region tag for it instead of some number of lines offset because this
number @b @e MUST change when lines are added or deleted in the skip
region, <b>MAKING THE WHOLE '@region... skip-lines]' CONSTRUCTION QUITE
FRAGILE<b>.

Instead, use of multiple region tags is
significantly more robust and may @e always be properly parsed by
Doxygen:

    @region region_tag_1
    ...
    @region region_tag_2
    ...
    @region region_tag_3

    ... common inclusion


    ... end the regions in any order,
        even with sequential lines:

    @endregion region_tag2

    ...

    @endregion region_tag_3
    @endregion regsion_tag1

Any missing tag of the pair @region/@endregion would be flagged as an
error, perhaps reading until end of file and flagging both a missing
@endregion and EOF conditon?  Would it als make more sense to scrub the
[skip-lines] and/or [region-label] concept entirely?

Anyway, I hope this helps.  Comments are solicited.



Dan Lydick

Re: [Doxygen-develop] Wish: have an unimplemented attribute

[Paul D. <duf...@gm...>]

>> But yes, I admit that it could be used for that. Maybe even to alias
>> \unimplemented to \todo would be nearer. But for me, I still think
>> that having an attribute just for that would be best.
>>
>
> What you're looking for is \xrefitem.
>
> http://www.stack.nl/~dimitri/doxygen/commands.html#cmdxrefitem
>
> Erik
>
> --
> *************************************************
> Erik Zeek
> ze...@ma...
> *************************************************

Hey, indeed it seems to be what I need. Thanks!

Re: [Doxygen-develop] Wish: have an unimplemented attribute

[Erik Z. <ze...@ma...>]

On Thu, Jul 31, 2008 at 4:47 PM, Paul Dufresne <duf...@gm...> wrote:
> 2008/7/31 Peter Münster <pm...@fr...>:
>> On Wed, Jul 30 2008, Paul Dufresne wrote:
>>
>>> Being able to add an unimplemented attribute, would be nice.
>>> Moreover if the list of functions (or members, etc) that still need to
>>> be implemented would be listed, perhaps inside the todo page.
>>
>> I think, this is just the purpose of the \todo command. I use it like this:
>> \todo still to be done
>> Cheers, Peter
>
> I'd prefer to keep todo for stuff like: reimplement using this, or
> move that code to ..., etc.
> But yes, I admit that it could be used for that. Maybe even to alias
> \unimplemented to \todo would be nearer. But for me, I still think
> that having an attribute just for that would be best.
>

What you're looking for is \xrefitem.

http://www.stack.nl/~dimitri/doxygen/commands.html#cmdxrefitem

Erik

-- 
*************************************************
Erik Zeek
ze...@ma...
*************************************************
Against stupidity the very gods
Themselves contend in vain.
 - Johann Christoph Friedrich von Schiller (1801)
*************************************************

Re: [Doxygen-develop] Wish: have an unimplemented attribute

[Paul D. <duf...@gm...>]

2008/7/31 Peter Münster <pm...@fr...>:
> On Wed, Jul 30 2008, Paul Dufresne wrote:
>
>> Being able to add an unimplemented attribute, would be nice.
>> Moreover if the list of functions (or members, etc) that still need to
>> be implemented would be listed, perhaps inside the todo page.
>
> I think, this is just the purpose of the \todo command. I use it like this:
> \todo still to be done
> Cheers, Peter

I'd prefer to keep todo for stuff like: reimplement using this, or
move that code to ..., etc.
But yes, I admit that it could be used for that. Maybe even to alias
\unimplemented to \todo would be nearer. But for me, I still think
that having an attribute just for that would be best.

Re: [Doxygen-develop] Wish: have an unimplemented attribute

[Peter M. <pm...@fr...>]

On Wed, Jul 30 2008, Paul Dufresne wrote:

> Being able to add an unimplemented attribute, would be nice.
> Moreover if the list of functions (or members, etc) that still need to
> be implemented would be listed, perhaps inside the todo page.

I think, this is just the purpose of the \todo command. I use it like this:
\todo still to be done
Cheers, Peter

-- 
http://pmrb.free.fr/contact/

[Doxygen-develop] Wish: have an unimplemented attribute

[Paul D. <duf...@gm...>]

For a big project, we sometime begin by writing stub functions just
returning a no error code. And it is sometimes hard to know what have
been implemented or not without going all the sources.

Being able to add an unimplemented attribute, would be nice.
Moreover if the list of functions (or members, etc) that still need to
be implemented would be listed, perhaps inside the todo page.

Re: [Doxygen-develop] Doxygen and /*!*****

[Dimitri V. H. <do...@gm...>]

Hi John,

I would find /*!****** acceptable indeed. /*********** gives too many  
false positives on legacy code, so that's not supported.
Something that already works is

/*********************//*!
   Hello there
************************/

But it has the side-effect that it shows /*******************/ in the  
source browser output...

So please submit a bug report with severity set to enhancement for it,  
and then attach the patch.

Regards,
   Dimitri

On 25 jul 2008, at 15:53, John Tapsell wrote:

> Hi all,
>
>  Would it be possible to add support for comments like
>
> /*!***********************************
>   Hello there!
> ***************************************/
>
>
> It don't think it would break anything to support these types of
> comments, and I can write a small patch to do this if I know such a
> change would be considered?
>
> Thanks
>
> John Tapsell
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] Doxygen and /*!*****

[John T. <joh...@gm...>]

Hi all,

  Would it be possible to add support for comments like

 /*!***********************************
   Hello there!
***************************************/


It don't think it would break anything to support these types of
comments, and I can write a small patch to do this if I know such a
change would be considered?

Thanks

John Tapsell

[Doxygen-develop] Documents & Examples for newbie developer ?

[Pei Wu <wu...@gm...>]

Hello community .

I've just got into Doxygen Dev.. in the project  I should develop a
functionality-extension of Doxygen so that it could process PLC programms
(Structured Text).  I found lots a documents about doxygen and was a little
lost.. 

Could someone give me some advices how I quickly 'enter ' ? 

Thank you in advance.
Pei
-- 
View this message in context: http://www.nabble.com/Documents---Examples-for-newbie-developer---tp18486997p18486997.html
Sent from the Doxygen - Development mailing list archive at Nabble.com.