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

Re: [Doxygen-develop] Aliases

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

On 31 jul 2009, at 11:41, John Tapsell wrote:

> Hey all,
>
>  At the moment you can't use cond inside an alias, like:
>
> ALIASES = foodev="\cond FooDev" \
>          endfoodev="\endcond"
>
> (http://bugzilla.gnome.org/show_bug.cgi?id=485773)
>
> Does anyone know of a work around?
>
> Can anyone give a hint how I could fix this bug in doxygen?

The problem is that both the ALIASES resolution and the processing of  
\cond..\endcond
section's are done in the same pass, in src/commentcnv.l.

To do this properly a two-pass approach would be needed.
First the ALIASES need to be resolved and then the \cond sections
need to be processed.

Alternatively, some special treatment could be given to
expanded aliases with \cond or \endcond commands.

Regards,
   Dimitri

[Doxygen-develop] Aliases

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

Hey all,

  At the moment you can't use cond inside an alias, like:

ALIASES = foodev="\cond FooDev" \
          endfoodev="\endcond"

(http://bugzilla.gnome.org/show_bug.cgi?id=485773)

Does anyone know of a work around?

Can anyone give a hint how I could fix this bug in doxygen?

John Tapsell

[Doxygen-develop] [PATCH] Add config options for putting constructors first

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there,

on KDE we use sorted member docs which is mostly great except for the fact 
that ctors/dtors get sorted with all of the other members while I'd really 
like them to be on top of the list.

As I couldn't find a way to put them on top, I added a new config option:
SORT_MEMBERS_CONSTRUCTORS_FIRST
which will always put constructors first, destructors after and all other 
members below. The option concerns brief-doc as well as detailed-doc sorting 
but will be ignored for either if SORT_BRIEF_DOCS=NO or SORT_MEMBER_DOCS=NO.

I couldn't find any coding style guide, so I hope I mimicked the style I 
found properly. Please tell me if you want me to change or have further 
suggestions for improvement.

Regards,
Michael Leupold
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFKb2zclfpzINIAlVsRApWgAJ0aCn8RNILCFBiZCmnvB+jdEV+XiACfb4j6
V2w1t+sNaUukc4aRlI2Fa0I=
=jNrG
-----END PGP SIGNATURE-----

Re: [Doxygen-develop] doxyparse addon - simple code parse based on doxyapp

[Joenio C. <jo...@pe...>]

ops!

I forgot the attachment.

-- 
Joenio Costa
- www.Colivre.coop.br
- www.Perl.org.br
- Salvador.pm.org

GNU/Linux User #431067 http://counter.li.org

On Tue, Jul 21, 2009 at 12:36:39AM -0300, Joenio Costa wrote:
> Hi Dimitri,
> 
> On Sat, Jul 18, 2009 at 04:54:16PM +0200, Dimitri Van Heesch wrote:
> > Sounds interesting.
> 
> Thanks!
> 
> > Can you give (a pointer to) more detailed information about
> > what the tool does? (i.e. the kind of dependencies it extracts, and the
> > form in which they presented)
> 
> Yes, sure!
> 
> Basically doxyparse extract informations about declarations and use of
> symbols found in source code. Follow a small example running doxyparse
> over addon/doxyapp sources:
> 
> ----------------------------------------------------
> ~/src/doxygen$ ./bin/doxyparse addon/doxyapp/
> module doxyapp.cpp
>    function findXRefSymbols in line 97
>    function listSymbol in line 120
>    function listSymbols in line 131
>       uses function listSymbol defined in doxyapp.cpp
>    function lookupSymbol in line 155
>    function lookupSymbols in line 204
>       uses function lookupSymbol defined in doxyapp.cpp
>    function main in line 233
>       uses function findXRefSymbols defined in doxyapp.cpp
>       uses function listSymbols defined in doxyapp.cpp
>       uses function lookupSymbols defined in doxyapp.cpp
> ----------------------------------------------------
> 
> Here doxyparse says for example:
> 
> "module doxyapp.cpp declares function findXRefSymbols"
> 
> > Can you make the changes available to developers that do not yet use
> > git (like myself)?
> > (i.e. as a tarball or as a patch on the current SVN repository)
> 
> Sorry!
> 
> I attach a diff in this email.
> 
> to compile:
> ./configure --with-doxyparse
> 
> > Regards,
> >  Dimitri
> 
> Best regards,
> -- 
> Joenio Costa
> - www.Colivre.coop.br
> - www.Perl.org.br
> - Salvador.pm.org
> 
> GNU/Linux User #431067 http://counter.li.org
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

Re: [Doxygen-develop] doxyparse addon - simple code parse based on doxyapp

[Joenio C. <jo...@pe...>]

Hi Dimitri,

On Sat, Jul 18, 2009 at 04:54:16PM +0200, Dimitri Van Heesch wrote:
> Sounds interesting.

Thanks!

> Can you give (a pointer to) more detailed information about
> what the tool does? (i.e. the kind of dependencies it extracts, and the
> form in which they presented)

Yes, sure!

Basically doxyparse extract informations about declarations and use of
symbols found in source code. Follow a small example running doxyparse
over addon/doxyapp sources:

----------------------------------------------------
~/src/doxygen$ ./bin/doxyparse addon/doxyapp/
module doxyapp.cpp
   function findXRefSymbols in line 97
   function listSymbol in line 120
   function listSymbols in line 131
      uses function listSymbol defined in doxyapp.cpp
   function lookupSymbol in line 155
   function lookupSymbols in line 204
      uses function lookupSymbol defined in doxyapp.cpp
   function main in line 233
      uses function findXRefSymbols defined in doxyapp.cpp
      uses function listSymbols defined in doxyapp.cpp
      uses function lookupSymbols defined in doxyapp.cpp
----------------------------------------------------

Here doxyparse says for example:

"module doxyapp.cpp declares function findXRefSymbols"

> Can you make the changes available to developers that do not yet use
> git (like myself)?
> (i.e. as a tarball or as a patch on the current SVN repository)

Sorry!

I attach a diff in this email.

to compile:
./configure --with-doxyparse

> Regards,
>  Dimitri

Best regards,
-- 
Joenio Costa
- www.Colivre.coop.br
- www.Perl.org.br
- Salvador.pm.org

GNU/Linux User #431067 http://counter.li.org

Re: [Doxygen-develop] doxyparse addon - simple code parse based on doxyapp

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

Hi Joenio,

On 11 jul 2009, at 01:52, Joenio Costa wrote:

> Hello,
>
> My name is Joenio and I am a graduate student in computer science,  
> in my
> graduate project I use doxygen to implement a simple source code parse
> called doxyparse to extract dependencies between code elements.
>
> The sources of this project are in:
>
> http://gitorious.org/doxygen
>
> Direct address of git repository is:
>
> git://gitorious.org/doxygen/mainline.git
>
> In this repository all doxyparse code is on doxyparse branch.
>
> I would be grateful if the project was accepted as part of doxygen.

Sounds interesting.

Can you give (a pointer to) more detailed information about
what the tool does? (i.e. the kind of dependencies it extracts, and the
form in which they presented)

Can you make the changes available to developers that do not yet use  
git (like myself)?
(i.e. as a tarball or as a patch on the current SVN repository)

Regards,
  Dimitri

[Doxygen-develop] Problems generating mixed c/fortran documentation

[don h. <hin...@gm...>]

Hi:

We have a large amount of legacy fortran code that is used in mixed
c/fortran libraries.  Some of this code is pretty old, but is still
maintained and, as mentioned, integrated into libraries comprised of c
code as well.  The original fortran files used include files with
common areas that were later used to generate c header files via a
modified version of f2c.

Therefore, all symbols have an underscore added to the end, although
we don't add additional underscores, just the one, and the c code code
that uses common areas or makes calls to the fortran subroutines or
functions, adds the underscore directly in the code, e.g., a fortran
subroutine foo(), would be called in c as foo_().  The f2c underscore
decoration makes it impossible to generate mixed c/fortran
documentation that contains appropriate links, since the symbols don't
match.  I realize there are header files that can do this for you, but
we don't use them

I initially modified the existing fortran lexers to accommodate the
underscore decoration, but quickly found other issues with the current
implementation that made it impractical to use it with our code base,
e.g., seg faults on sun, so I decided to rewrite it with a proper
lexer in flex, and parser in bison.  We only use fixed format
fortran77, with some extensions, so my current iteration does not
include any F90 syntax at this point, however, that should be a simple
matter of adding that to the bison grammar.

I just got permission for my employer to submit back patches to the
doxygen project, but would first like to work with some of the fortran
users/developers to make sure the new parser works correctly for both
fixed format and current free format fortran code (I've only been
working with fortran for the past 12 months, and have only been using
legacy fortran77).  Once the parser is has been enhanced/validated, it
shouldn't take long to get a patch ready.

Please let me know if you are interested.

thanks...
don

[Doxygen-develop] doxyparse addon - simple code parse based on doxyapp

[Joenio C. <jo...@pe...>]

Hello,

My name is Joenio and I am a graduate student in computer science, in my
graduate project I use doxygen to implement a simple source code parse
called doxyparse to extract dependencies between code elements.

The sources of this project are in:

http://gitorious.org/doxygen

Direct address of git repository is:

git://gitorious.org/doxygen/mainline.git

In this repository all doxyparse code is on doxyparse branch.

I would be grateful if the project was accepted as part of doxygen.

Thanks!
-- 
Joenio Costa
- www.Colivre.coop.br
- www.Perl.org.br
- Salvador.pm.org

GNU/Linux User #431067 http://counter.li.org

[Doxygen-develop] Feature Request: @page in a group

[Stefan-Heiss <Ste...@in...>]

If it's technical feasible, I do miss a possibility to place a page generated
via the @page command, into a group defined by @defgroup.

This feature would give us the possibility to easily cusomtise the
documentation of a module for instance.

Example of feature requested:
----------------------------------
/**
 * @defgroup MY_API
 */

/**
 * @page PAGE_IOCTL Supported IOCTL
 * @ingroup MY_API
 */
---------------------------------

Besides the regular documentation generated by doxygen, this feature would
show the PAGE_IOCTL within the MY_API module documentation.


-- 
View this message in context: http://www.nabble.com/Feature-Request%3A-%40page-in-a-group-tp24164592p24164592.html
Sent from the Doxygen - Development mailing list archive at Nabble.com.

[Doxygen-develop] Disable "generated on" text in HTML footer by default

[Michal S. <ms...@su...>]

Hi!

There is a problem with same packages which are build in different time
and which use doxygen to build doc part
This "generated on" feature in HTML footer causes diff in doc part,
which is not easy to recognize as "real change", so it's problem to
check if generated package was really changed or not
I know there is a option to fix this issue through the HTML_FOOTER, but
for build system which build hundreds of open source packages
 you need to patch each package separately
So I want to know if disable "generated on" by default is right and if
would be possible to fix it

patch attached,
http://bugzilla.gnome.org/show_bug.cgi?id=579303

thanks
Michal

[Doxygen-develop] DBus XML parser

[Tobias H. <to...@aq...>]

Hi everybody!

Attached you will find a initial version of a DBus XML parser for doxygen.

D-Bus interfaces are part of the public interface of a program. So D-Bus 
interfaces need to get documented. Having doxygen support this is nice as its 
syntax is well known, developers probably know it already and there is a good 
chance of the buildsystem already supporting doxygen:-)

So far this code only allows for documentation of interfaces, methods and 
signals. It would make sense to add a (non-standard) extension to the D-Bus 
XML which allows to add documentation to types used.

I would be happy if somebody could take the time to review the patch and even 
more happy if somebody could apply it:-)

Best Regards,
Tobias

[Doxygen-develop] Is possible to Doxygen extract external symbols?

[Joenio C. <jo...@pe...>]

Hi people,

I'm starting an addon based on doxyapp example to extract symbols and funcion
call of an project and i need extract use of external symbols too, (i.e. use of
printf or functions provided by external libs).

Its possible?

ps.: the code of addon is here:
http://wiki.dcc.ufba.br/pub/Aside/ProjetoFinalJoenioCosta/doxyparse.tar.gz

Thanks!
-- 
Joenio Costa
- www.Colivre.coop.br
- www.Perl.org.br
- Salvador.pm.org

GNU/Linux User #431067 http://counter.li.org

[Doxygen-develop] Warning output line problems

[Istvan H. <ho...@gm...>]

Hi All,

I have two little problems with warning messages doxygen outputs.

1. In message.cpp right before the last line I'v added this little snippet
 
// beginning of my modification
  if (msgText.contains("$warn-to-lower",FALSE)) {
    msgText = substitute(msgText, "$warn-to-lower", "");
    msgText = substitute(msgText, "Warning:", "warning:");
  }
// end of my modification

  // print resulting message
  fprintf(warnFile,msgText);
}

This tiny modification added support of a new WARN_FORMAT
 tag $warn-to-lower. This new tag is intended to let control the case of
'warning' word in the output warning message.
If presented the output will print 'warning:' instead of the original
'Warning:' text in the message.
The reason is why I had to add this is that the Apple Xcode parses gcc
compiler output wrongly, could not differentiate between the two cases and
therefore treats Doxygen warnings as errors.
Because Apple surely won't fix this I hope doxygen could do it in one of the
feature releases, may be via something similar solution like mine.

2. Also there's another problem with the output in Xcode. Doxygen has some
warning messages that has not the word 'warning' at all in the outputed
line. Like, 
group "group_name": ignoring title "description" that does not match old
title "old_description"
The problem is the same like above, Xcode treats these lines as errors.
If these are really errors than that would be nice if the 'error' word and
if these are warnings than the 'warning' word would be added to the produced
output lines.


Thank you in advance
Bests 
Hofi 

Re: [Doxygen-develop] dynamic 'protected' display

[Chris C. <do...@ke...>]

On Wed, Apr 22, 2009 at 10:30:06PM -0400, Ethan Tira-Thompson wrote:

> Another feature I am interested in is extending HTML_DYNAMIC_SECTIONS  
> to allow users to show or hide the 'protected' fields.
> 
> Some classes are meant to be used 'as is', and protected methods/ 
> members are only intended for future expansion by the library authors,  
> and so are not of interest to library users reading the documentation.
> 
> Other classes are meant to be subclassed by end-users, in order to  
> pass their classes back into the library.  In this case they would be  
> interested in the documentation for protected methods.

If I understand your idea, a good example would be the STL iostreams
classes.  Most people are only interested in using the public
interfaces, but implementorsneed the documentation of the protected
virtual functions so that they can provide the implementation of the
'hooks' (for instance a TCP/IP socket stream which isn't in the standard
but can be implemented quite easily -- I know of several implementations
including my own).

If I understand you, the idea is to allow such data to be 'unfolded' at
will by the programmer, rather than having to run the whole thing
through Doxygen with different settings.  This strikes me as a good
idea, since the documentation is often on a website and not easily
re-created (it required that the user has Doxygen, for a start).

Chris C

[Doxygen-develop] dynamic 'protected' display

[Ethan Tira-T. <ej...@an...>]

Another feature I am interested in is extending HTML_DYNAMIC_SECTIONS  
to allow users to show or hide the 'protected' fields.

Some classes are meant to be used 'as is', and protected methods/ 
members are only intended for future expansion by the library authors,  
and so are not of interest to library users reading the documentation.

Other classes are meant to be subclassed by end-users, in order to  
pass their classes back into the library.  In this case they would be  
interested in the documentation for protected methods.

Examples in our robotics code are Event classes, which are posted by  
the framework and not generally subclassed by users, vs. Behavior and  
Motion classes, which explicitly designed for users to inherit and  
extend.

So what I would like to see is a way to add a "show protected members"  
link on the HTML output so by default it can be hidden, but still be  
available to expand for users who are going to be extending the  
class.  A good implementation might allow individual classes to  
specify whether they display the protected section by default  
depending on expected usage.

HTML_DYNAMIC_SECTIONS might be made a list of section names instead of  
a boolean so users could always display the inheritance graph but  
collapse the 'protected' stuff, and not include 'private' stuff at  
all...

Thoughts?

thanks,
   -Ethan

[Doxygen-develop] List of inherited members?

[Ethan Tira-T. <ej...@an...>]

It seems doxygen is all-or-nothing about including inherited  
methods... Either you enable INLINE_INHERITED_MEMBERS and the  
inherited functions are listed alongside the local/overridden methods,  
or you disable INLINE_INHERITED_MEMBERS, and see nothing.

I find the way javadoc handles this much better for exploring class  
functionality: only the functions which are directly part of the class  
are verbosely listed, and inherited methods are given a succinct list,  
ordered by class.  This is a good compromise, allowing you to see what  
is added/unique about a given class, but also see at a glance what it  
offers via its superclasses as well.

Would this be hard to add?  Is anyone working on such a thing?

thanks,
   -Ethan

[Doxygen-develop] Do not discard unknow commands

[Hugo L. <hug...@op...>]

Hi;

I'm using doxygen to read the API documentaion of a third part
software, so I can't change the documentation inside the source code,
but doxygen give me a XML in their ouput and I can change it to
anything that I want, but there is a problem.

The documentation have some commands not recognized by doxygen, and
when doxygen find one of then it simply discard the comman characters
from the output, my patch tell doxygen to not discard unknow commands
characters.

I think that this patch do not affect the normal use of doxygen, the
current behaviour is undesired by the user, just as the new behaviour,
because the documentation must nto have any unknow commands.

Any comments?

[Doxygen-develop] New release?

[Leandro L. <ll...@gm...>]

Hi. Is there any information on when a new Doxygen release will be done?

There are several serious bugs fixed that it would be great to have in
a release (like #573838).

Thank you.

PS: Please CC me

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------

[Doxygen-develop] Call / Caller graphs with smart pointers

[Jeffrey N. <jef...@gm...>]

I asked the below question on the Doxygen-users group, and I'm
assuming by the lack of responses I received that this functionality
is not available.  This is something that would be very useful to me,
and I'm hoping it's relatively simple to add.  Could anyone point me
in the right direction on where I would start?  Keep in mind that I've
never looked at Doxygen's source.  Either a pointer to some high-level
documentation, or a few important classes would be great.

Thanks!
Jeff Newman


From: [Doxygen-users] Call / Caller graphs with smart pointers

Hello,

Is there any way to get Doxygen's call and caller graphs to recognize
calls made through a smart pointer in C++? The graphs that I currently
have doxygen generating find calls made through a standard pointer or
dot notation, but get lost with anything like an auto_ptr or
shared_ptr. This makes the graphs much less useful, since my code base
makes significant use of smart pointers like this.

As a side question, I was trying to search this mailing list through
sourceforge's archive, but couldn't find anything that was working.
Is there a good way to search the archives? (My apologies if this
question has already been asked).

Any help is greatly appreciated!

[Doxygen-develop] subpages without the link.

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

With some of my XML changes, I have found that it would be really useful 
if \subpage didn't actually create a link, but just made the page a 
subpage silently, much like \ingroup does for Modules.

What would I need to do to add an alternative to \subpage that only 
links the page parent to child? I know enough about the backend system 
to make \subpage do it, but I know nothing about creating new commands.

[Doxygen-develop] When the .CHM file is opened, it silently doesnt get recompiled

[Edgar 't H. <edg...@gm...>]

hi,

I sometimes noticed my .chm file didnt get updated. But this is due to
the fact that the .chm file was already open(but minimized, or
hidden).
Doxygen nor the hhc.exe where telling me the pre-existing .chm file
was already opened, or could not be deleted..

I made a small patch, which tries to zero the destination .chm file,
if it already exists.
When it exists, it will put out a message, Removing previous .chm.
Then it tries to open the file in write-mode, if this fails, an err is
shown: Error: CHM file is already open, cant continue...
I didnot change anything to the existing behaviour. I just added some
usefull messages, to detect something is going wrong.
So existing users should not have any problem with this patch.

This is the patch:
Doxygen.cpp - line 10443:
  if (Config_getBool("GENERATE_HTML") &&
      Config_getBool("GENERATE_HTMLHELP") &&
      !Config_getString("HHC_LOCATION").isEmpty())
  {
    msg("Running html help compiler...\n");
    QString oldDir = QDir::currentDirPath();
    QDir::setCurrent(Config_getString("HTML_OUTPUT"));

    bool bCHMAllowed = true;
    QCString& chmFile =   Config_getString("CHM_FILE");
    QFileInfo fi(chmFile);
    if (fi.exists() && fi.isFile())
    {
      msg("Removing previous .chm\n");
      QFile zero_length_file(chmFile);
      if (zero_length_file.open(IO_WriteOnly))
      {
        zero_length_file.close();
      }
      else
      {
        err("Error: CHM file is already open, cant continue...\n");
        bCHMAllowed = false;
      }
    }

    if ( bCHMAllowed==false ||
portable_system(Config_getString("HHC_LOCATION"), "index.hhp", FALSE))
    {
      err("Error: failed to run html help compiler on index.hhp\n");
    }
    QDir::setCurrent(oldDir);
  }

Together with this patch, which tells the user doxygen is finished,
the Doxygen application became a bit more monkey-proof.
Doxygen.cpp - line 10526:

  msg("\
-------------------\n\
Doxygen finished...\n\
-------------------\n");

Regards,
Edgar

[Doxygen-develop] Bug: Incorrect <> / "" in Class Reference page

[Edgar 't H. <edg...@gm...>]

I forgot to mention this..

This one DOES calculate the local flag correctly:

FileDef::addIncludeDependency

So the link is shown correctly (#include "Test.h") on the File Reference Page.

So it seems just a problem in Doxygen.cpp - void addIncludeFile (...)
Which calculated the local flag, for the Class Reference Page

Edgar

[Doxygen-develop] Fix: html links to File Reference pages

[Edgar 't H. <edg...@gm...>]

I have made a fix, maybe some one can verify this.

When SOURCE_BROWSER not configured, I now get a HTML link from the
'CTestExtra Class Reference' page, to the 'TestExtra.h File Reference'
page.

I have one minor problem... In my current project the 'local' flag is
not always set for local include files.
So var local == false.
The only problem I have is that the include is sometimes showed as
#include <test.h> in stead of #include "test.h"
But I think I noticed this problem earlier today also, before I
started hacking the code..
StdAfx.h works OK, but my TestExtra.h doesnt... Strange.
I have a really small test project, in case some one has any idea.

Below my changes, to get some working HTML Links..

Regards,
Edgar


Doxygen.cpp - line 769:
      if ( fd->generateSourceFile()) // generate code for header
      {
        cd->setIncludeFile(fd,iName,local,!root->includeName.isEmpty());
      }
#ifndef ETA_CHANGE
	  else if ( fd->isLinkable())
	  {
		  cd->setIncludeFile(fd,iName,local,!root->includeName.isEmpty());
	  }
#endif // ED
      else // put #include in the class documentation without link
      {
        cd->setIncludeFile(0,iName,local,TRUE);
      }

classdef.cpp - line 1247 :
      if (m_impl->incInfo->fileDef)
      {
#ifndef ETA_CHANGE
		  if ( m_impl->incInfo->fileDef->isLinkable() )
			  ol.writeObjectLink(0,m_impl->incInfo->fileDef->getOutputFileBase(),0,nm );
		  else
#endif // ETA_CHANGE
			  ol.writeObjectLink(0,m_impl->incInfo->fileDef->includeName(),0,nm );

      }

[Doxygen-develop] Bug?: #Include "..." not shown as a HTML link

[Edgar 't H. <edg...@gm...>]

Hi,
I am creating some documentation of our sources, with the
SOURCE_BROWSER setting set to TRUE, I see a correct HTML link in my
"CTestExtra Class Reference" to the .h file in which it was declared.
When clicking this link, it jumps to my 'TestExtra.h' page, fromwhich
I can jump to 'Go to the documentation of this file.' the 'TestExtra.h
File Reference' page.

But I do not want SOURCE_BROWSER enabled, because I dont want our .h
files to be in the documentation. I have set VERBATIM_ HEADERS to
FALSE.
I do have enabled the SHOW_INCLUDE_FILES.
When I now open my 'CTestExtra Class Reference' the
#include <TestExtra.h>
but it is not shown as a link.

I have traced the problem to:
Doxygen.cpp - line 769:
      if ( fd->generateSourceFile()) // generate code for header
      {
        cd->setIncludeFile(fd,iName,local,!root->includeName.isEmpty());
      }
      else // put #include in the class documentation without link
      {
        cd->setIncludeFile(0,iName,local,TRUE);
      }


Can I let the "CTestExtra Class Reference" page's #include
"TestExtra.h" make it jump directly to 'TestExtra.h File Reference'

The link at the bottom of the class reference page does seem to work correctly
When looking at classdef.cpp - line 992:
        if (fd->generateSourceFile())
        {
          ol.writeObjectLink(0,fd->getSourceFileBase(),0,fname);
        }
        else if (fd->isLinkable())
        {
          ol.writeObjectLink(fd->getReference(),fd->getOutputFileBase(),0,
              fname);
        }
        else
        {
          ol.docify(fname);
        }

I see there are three possibilites, 1:link_to_code_file,
2:link_to_file_reference(the one I also want), 3:plain_text

Could some help me solve this ?

Regards,
Edgar

[Doxygen-develop] Submitting a patch?

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

I have a patch containing a much-improved XML format (it still produces 
the old one, but it can also produce a new one). It seems stable enough, 
and integration shouldn't be too much of a problem. And it is built 
against 1.5.8. However, I don't know where to send it for evaluation and 
submission.