4 Apr 2007 17:54

### .rules generation

Hi there.

I think it would be really cool to add the following functionality to doxygen at compile-time. As a warning, I have used doxygen but haven't messed with its source code, so apologies if what I propose is silly or unfeasible.

I believe some sort of modification to config.h would allow for generation of an MSVC .rules file similar to (but obviously huger than) than the following:

<?xml version="1.0" encoding="utf-8"?>
<VisualStudioToolFile
Name="doxygen"
Version="8.00"
>
<Rules>
<CustomBuildRule
Name="doxygen"
DisplayName="doxygen"
CommandLine="echo <at> INCLUDE = [inputs]&gt;$(IntDir)\$(InputName).temp&#x0D;&#x0A;[AllOptions]&#x0D;&#x0A;doxygen $(IntDir)\$(InputName).temp"
Outputs="$(OutDir)\html\index.html" FileExtensions="*.doxygen" ExecutionDescription="Generating doxygen documentation..." > <Properties> <StringProperty Name="PROJECTNAME" DisplayName="Project name" Category="Project" Description="The project name." HelpURL="http://www.stack.nl/~dimitri/doxygen/config.html#cfg_project_name" Switch="echo PROJECT_NAME=[value]&gt;&gt;$(IntDir)\$(InputName).temp &amp;" DefaultValue="$(ProjectName)"
/>
<StringProperty
Name="OUTPUTDIRECTORY"
DisplayName="Output directory"
Category="Project"
Description="The output directory for generated documentation."
HelpURL="http://www.stack.nl/~dimitri/doxygen/config.html#cfg_output_directory"
Switch="echo OUTPUT_DIRECTORY=[value]&gt;&gt;$(IntDir)\$(InputName).temp &amp;"
DefaultValue="$(OutDir)" /> <EnumProperty Name="BRIEFMEMBERDESC" DisplayName="Brief Member Desc" Category="Project" Description="Include brief member descriptions after the members." HelpURL="http://www.stack.nl/~dimitri/doxygen/config.html#cfg_brief_member_desc" DefaultValue="1" > <Values> <EnumValue Value="0" Switch="echo BRIEF_MEMBER_DESC=NO&gt;&gt;$(IntDir)\$(InputName).temp &amp;" DisplayName="No" /> <EnumValue Value="1" Switch="echo BRIEF_MEMBER_DESC=YES&gt;&gt;$(IntDir)\\$(InputName).temp &amp;"
DisplayName="Yes"
/>
</Values>
</EnumProperty>
</Properties>
</CustomBuildRule>
</Rules>
</VisualStudioToolFile>

This would allow for .doxygen files to have their own configuration section in the project settings. Basically, the rule file generates a temporary doxygen file on the fly and then runs doxygen, all based on user-selected parameters in the project settings. I don't foresee this being terribly difficult to do. Another advantage is that it's portable - if you want to carry the project over to posix, just take the generated doxygen file and ignore the MSVC project file.

What do you think?

--

Greg Toombs
Software consultant
Mountain Path Consultation
(519) 400-0065

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Doxygen-develop mailing list
Doxygen-develop <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/doxygen-develop
11 Apr 2007 11:38

### Undeserved explicit link warnings with 1.5.2

Hi All,
I'm getting warnings like

myFile.cpp:2: Warning: explicit link request to 'myFunction' could
not be resolved

The documentation source in question is a "#myFunction" reference in
the  <at> file section of myFile.cpp.

They're being generated by calls to docparser.cpp's handleLinkedWord
from the buildFileList call of parseInput. Note that myFunction is
indeed a documented function. The generated documentation is actually
correct - when handleLinkedWord is called from doxygen.cpp's
in the final generated documentation.

The first call (the one that produces the warnings) is via
Definition::_setBriefDescription, which calls parseCommentAsText in
order to garner the tooltip text - so iiuc it doesn't need to expand
the links anyway. I hacked up a quick change using a global set by
validatingParseDoc to arrange handleLinkedWord to just return a
DocWord always, and arrange for only the call from parseCommentAsText
to set the global. This appears to fix the problem, but maybe there's
a better way to address this ?

To a first glance/guess, it looks like the early warnings are being
produced because the functions have not yet been parsed, and so the
references to them are unknown. I get a few other cases, some when
variables reference function names, and occasionally when variables
reference other variables.

The same issue occurs for \ref links in the same context, and for the
same reasons. A simliar change (using the same global) in
DocRef::DocRef also fixes this.

i'm happy to post my patch if that's desired, but if there's a better
way to attack this, lmk and (time permitting) i'll have a go at
implementing that.

This happens both with a self compiled exe and with the distributed
zipped binaries (windows).

- robbie

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
20 Apr 2007 21:21

### Re: Ada parser support (was: Fortran90 parser: interest?)

Howdy:

I just got the email announcing that Aonix is going to release the
source for their ADT plugin for Eclipse as a new Eclipse project.
Great, you're thinking, but how does that help Doxygen?  Well, the way I
understand the Eclipse design, the plugins generally include their own
compiler (of a sort) as part of the language IDE.  This is the way they
do code analysis in Eclipse, build the abstract syntax trees, etc.

So maybe I'm way off base here, but I'm think there should be a way to
leverage that code into an Ada parser for Doxygen.

Thoughts?

Steve

PS. I got yanked into a bunch of review meetings, but I hope to test my
ada2cpp idea soon (unless somebody else gets to it first...).

> -----Original Message-----
> From: doxygen-develop-bounces <at> lists.sourceforge.net
> [mailto:doxygen-develop-bounces <at> lists.sourceforge.net] On
> Behalf Of Jeffrey Creem
> Sent: Thursday, March 01, 2007 4:08 PM
> To: doxygen-develop <at> lists.sourceforge.net
> Subject: Re: [Doxygen-develop] Fortran90 parser: interest?
>
> Arnold.Steve wrote:
> > I could use Fortran support in general, as well as Ada83/95...
> >
> > So yes, I'd day there's definitely interest.
> >
> > Steve
> >
> > --
> > Stephen L. Arnold
> >
> >
> I agree. fortran support would be good. Ada 95/2005 support would be
> even better.
>
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the
> chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
&CID=DEVDEV
> _______________________________________________
> Doxygen-develop mailing list
> Doxygen-develop <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>

The information contained in this email message is intended only for the use of the individuals to whom it is
addressed and may contain information that is privileged and sensitive. If the reader of this message is
not the intended recipient, you are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited. If you have received this communication in error, please
notify the sender immediately by email at the above referenced address. Thank you.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
23 Apr 2007 01:54

### Patches for doxygen

Hi all,

I have been working on a project that interoperates with Doxygen to
produce accurate/complete documentation of C++ exception propagation.
Anyhow, in order to get my project to work I have had to make a few
patches to doxygen.

In particular the patches include:

-----------------
* Facility to match template types with "explicit" parameters for
defaults. For example:

void Function(std::vector<int>&);

can now be identified using:

void Function(std::vector<int,std::allocator<int> >&)

This works recursively and matches as best it can.

-----------------
* Merging of two sets of documentation for a single node.

For example:

/** \brief Brief 1.
*
* Detailed 1.
*/
void Function();

/** \fn Function1()
* \brief Brief 2.
*
* Detailed 2.
*/

The patch will attempt to merge the two documentation blocks instead
of just ignoring the second. The resulting detailed section will include:

Detailed 1.
Detailed 2.

Where as the brief will only keep the first brief found. This is
because I could not think of a good way to merge two brief sections. I
may later choose to merge the second brief as a part of the detailed
section so it is not lots completely.

-----------------
* Updated processing of input source files to be processed in the
order they are declared in the doxygen configuration file instead of
alphabetical order.

This was necessary because of the previous patch. I.e. the order of
processing was important to ensure that the "correct" brief
description was used for the documentation.

-----------------
* Type matches can now ignore a reference parameter to obtain a match.

This is generally not a good idea. I can understand if this patch
is not accepted. I had to do it because of a limitation in my project.
The reasons for this are described below:

int BackFunction(std::string);
class C
{
int Function(std::string s)
{
return BackFunction(s);
}
};

The above code when compiled with GCC will be MODIFIED internally by
the compiler to look like:

int BackFunction(std::string);
class C
{
int Function(std::string& s)
{
return BackFunction(s);
}
};

Notice the & added after the std::string. My project uses GCC to
generate data files that are then processed and as such when it emits
the results, the function is emitted like:
int C::Function(std::string&)

which doxygen does not consider the same as:
int C::Function(std::string)

For good reason as it is NOT the same. Anyhow i needed to support this
(at least for now). I can understand if this would not be accepted
into doxygen as a result. I need to speak with the GCC devs more to
find out if there is a method of obtaining the actual declared name
for the above function that does not include the &.

Would the doxygen community be interested in accepting some or all of
these patches?

If so i will have to clean them up a little first (I used STL strings
and lists as I am comfortable with them and have never used the QT
ones before, so i will have to update the code to make use of the QT
utilities before submission of the patch).

For a reference the project is called EDoc++
http://edoc.sourceforge.net/

Thanks,
Brendon.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
29 Apr 2007 15:23

Hello!

I'll be trying to extend doxygen to parse upcoming features of C++0x,
namely concepts. I have a few questions.

1) What places should I look for to make the appropriate changes? I
started to modify the scanner.l. I would like to make doxygen generate
list of concepts in a file - where's the code that does for classes,
functione, etc.?

2) What's the structure of the entry tree? Say I'm parsing a namespace:

namespace ns
{
// a class
// a concept
// something else
}

When I'm parsing the concept what does the "current" variable point to?
To the entry of the class? Should I make a new entry and make it a child
of the class or a child of the namespace?

3) How do I handle comments that are put just before the concept? Do I
have to write scanner rules for them, or are there some available
I should be aware of?

4) Concepts can be refined - it's pretty much an inheritance. Are there
any function to build the inheritance diagram?