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

Re: [Doxygen-develop] Maintainance of the "Projects that use doxygen" page

[Sebastian P. <web...@ha...>]

Kevin McBride wrote:
> Please make sure that my project, libteklti
> [http://sourceforge.net/projects/libteklti] is added to the list.

---------------------------------------------------------
Added. Should be online soon.



Sebastian

Re: [Doxygen-develop] Maintainance of the "Projects that use doxygen" page

[Sebastian P. <web...@ha...>]

Kevin McBride wrote:
> Please make sure that my project, libteklti
> [http://sourceforge.net/projects/libteklti] is added to the list.

-----------------------------------------------------------
Sure. Please let me know what text you want
for the description. I think it should answer
these questions:
 * sharp summary of function and problem domain
 * license
 * supported platforms
 * programming language(s) used

(Yes, I could try to write this summary myself
but this is in my eyes something the program
authors should do themselves.)



Sebastian

Re: [Doxygen-develop] Maintainance of the "Projects that use doxygen" page

[Kevin M. <ke...@pl...>]

Please make sure that my project, libteklti
[http://sourceforge.net/projects/libteklti] is added to the list.

Thank you,

- KJM


Sebastian Pipping wrote:
> Dimitri van Heesch wrote:
> 
>>I think there are two ways to proceed.
>>1) I send you the current source page (the raw page without the headers
>>and side panel)
>>    and you update it on a regular basis, send me the result and I
>>upload it to my site.
>>2) We move to page to sourceforge altogether and I add you as a
>>developer so you can
>>    update it completely independent of me.
>>
>>I would propose to start with option 1) and see if that is workable. If
>>not then go to option 2), ok?
> 
> 
> -------------------------------------------------------------------
> I don't think we can go for 1) as a longterm solution
> but we can start with that. Thank you!
> 
> 
> 
> Sebastian
> 
> 
> -------------------------------------------------------------------------
> 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
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
> 

Re: [Doxygen-develop] Maintainance of the "Projects that use doxygen" page

[Sebastian P. <web...@ha...>]

Dimitri van Heesch wrote:
> I think there are two ways to proceed.
> 1) I send you the current source page (the raw page without the headers
> and side panel)
>     and you update it on a regular basis, send me the result and I
> upload it to my site.
> 2) We move to page to sourceforge altogether and I add you as a
> developer so you can
>     update it completely independent of me.
> 
> I would propose to start with option 1) and see if that is workable. If
> not then go to option 2), ok?

-------------------------------------------------------------------
I don't think we can go for 1) as a longterm solution
but we can start with that. Thank you!



Sebastian

Re: [Doxygen-develop] Maintainance of the "Projects that use doxygen" page

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

Hi Sebastian,

Sorry for not replying before. As usual I was too busy at the
time I read your mail and it then forgot about it later on :-(

I really appreciate your offer and would like to make use of it.

You are right in that the page does not get updated as often as it should.
I think there are two ways to proceed.
1) I send you the current source page (the raw page without the headers and
side panel)
    and you update it on a regular basis, send me the result and I upload it
to my site.
2) We move to page to sourceforge altogether and I add you as a developer so
you can
    update it completely independent of me.

I would propose to start with option 1) and see if that is workable. If not
then go to option 2), ok?

Thanks again for your offer to help,

Regards,
  Dimitri


On 2/27/07, Sebastian Pipping <web...@ha...> wrote:
>
> Hello again!
>
>
> If you don't want me for the maintainer please
> let someone else do that job - just don't let the
> page die. Please say a word to this, I don't like
> talking to myself.
>
>
>
> Sebastian
>
>
> -------------------------------------------------------------------------
> 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
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>

Re: [Doxygen-develop] Maintainance of the "Projects that use doxygen" page

[Sebastian P. <web...@ha...>]

Hello again!


If you don't want me for the maintainer please
let someone else do that job - just don't let the
page die. Please say a word to this, I don't like
talking to myself.



Sebastian

[Doxygen-develop] Maintainance of the "Projects that use doxygen" page

[Sebastian P. <web...@ha...>]

Hello everybody!


I think it was several months ago when I sent in requests for
additions to the doxygen users page to Dimitri. Nothing happened
and from monitoring that page I know that is has not seen
any additions at all for a long time.

But I'm not here to complain - I am here to offer help.
I'm here to ask for the right to help maintaining that page.
The list is not structered, might contain broken links and
is getting more out of date every day. I don't need exclusive
rights - I just want to be in the set of people maintaining
this page so it stays part of the present, not past.

I am one of the maintainers of the application section
on the XSPF website (http://www.xspf.org/applications/)
so this is not a new job to me.

Please let me know if you are interested in working together.
My SourceForge nick is "hartwork" in case write access
is bound to project membership.



Sebastian

[Doxygen-develop] Feature request

[Brendon C. <bc...@av...>]

Hi All,

(Feature request is at end of email if you are not interested in the
reason why I request it).


For a while I have been writing a tool that will allow C++ developers
to generate documentation with a comprehensive list of exceptions that
may propagate from any function. It does a number of other exception
checks that check for dangerous/erroneous usage of exceptions.

Relevant to doxygen though, I am trying to get it to generate a file
that can be processed by doxygen as a standard source file in order to
add exception documentation to a functions doxygen documentation.


It will currently generate a file with documentation for all functions
that can throw exceptions in a format like:

/*! \fn Func(std::ostream&, addrinfo const*)
 *
 * Throws Exceptions:
 *    - SysSocketException
 *       - Originating from: GetAddress(sockaddr const*)
 *          - E: OtherFunction(std::ostream&)
 *          .
 *       .
 *
 *    .
 */

This file would be included by the doxygen parser along with all other
source files and add the exception information to the functions
existing documentation.

The amount of information generated is configurable, but as an example
the above displays that the function: Func(std::ostream&, addrinfo
const*) can throw a single exception of type: SysSocketException which
was originally thrown in a function called GetAddress().

The E: OtherFunction() line is currently optional and tells the user
that Func() makes a call to OtherFunction() which is the place where
the exception may enter Func(). This allows users to identify where in
the current function an exception will come from.

Now the problem is that I have a standard way of representing
constness for function parameters. For example:
GetAddress(sockaddr const*)

where in doxygen it is expecting whatever the user specified in the
source file (Which can from what I understand may differ in terms of
textual content but not semantics between the definition and
implementation). So doxygen will fail to automatically create a link
for a lot of my functions.

This becomes even more of a problem when as in the above example the
function to which the documentation will belong is not identified so
the \fn command is unable to find the function which this
documentation block should belong.


--- Feature Request --

Anyhow, as a feature request is it possible to request that doxygen be
updated to recognise function parameters like: "sockaddr const*" to be
the same as: "const sockaddr*"?

This feature could possibly be achieved with some simple text pattern
matching. I would also request that it match regardless of whether the
"struct" keyword is in the text also.


Thanks,
Brendon.

[Doxygen-develop] Long standing bug in doxygen

[Tim M. <tim...@bi...>]

Hi all,

There's been a bug in doxygen for several years now, and I'm hoping to 
get it patched in the main code. I actually first mentioned this bug on 
the list in 2003, but failed to actually bring it up as a change that 
needs to be made: Doxygen looks for an &tm; for the trademark symbol, 
where the actual (HTML/XML) symbol should be ™. There are only two 
changes that need to be made to fix this:

docparser.cpp, line 1313:
  else if (symName=="&tm;")    return DocSymbol::Tm;
change to
  else if (symName=="™")    return DocSymbol::Tm;
htmldocvisitor.cpp, line 104:
    case DocSymbol::Tm:      m_t << "&tm;"; break;
change to
    case DocSymbol::Tm:      m_t << "&trade;"; break;

&tm; doesn't do anything in Firefox at least. If someone needs backwards 
compatibility with &tm; then the first change is to insert the line with 
&trade; instead of replacing the other line.

Tim

Re: [Doxygen-develop] Publishing in SVG

[Augusto J. D. <au...@ic...>]

Rick wrote:
[...]
> My first thought is to just take the HTML ouput and post-process it,
> and this I can surely do.
[...]

Doxygen also outputs XML: http://www.stack.nl/~dimitri/doxygen/starting.html


Cheers,

-- 
Augusto Jun Devegili
http://devegili.org

Code is poetry

[Doxygen-develop] Publishing in SVG

[Rick <gra...@gm...>]

Hello all.

First of all let me state that doxygen rocks!  I'll leave it at there
since you all know that.

I have a question, I wasn't sure whether to post this on the user list
or this list.  I picked this one.

To cut to the quick, I'd like to publish docs in SVG.

more detail...

I'm developing a platform that is basically an internet SVG
presentation layer.  SVG is a W3C xml vector graphics standard that
can be compared in many ways to Flash.  SVG is XML.  The client is a
web broswer, supporting SVG either natively, or via a plugin.  We are
developing a viewer, as a plugin initially, and eventually there will
be a standalone client.

The backend runs on a Linux server, or servers, and leverages Apache
as an internet gateway.

The server suite will act as a host for application services.

User documentation, with the exception of setup and troubleshooting,
will be published in SVG, naturally, since that is the client
interface.

Backend documentation, the API, could benefit from being published in
SVG as well, and this is where my question arises.

I will publish the API through doxygen, and most certainly in HTML and
(ugh) Word.  I'd like to coerce it to publish SVG.

My first thought is to just take the HTML ouput and post-process it,
and this I can surely do.

I don't know much about how doxygen works, which is a testament to its
excellence, I don't need to.

Is there a better way?


zz
-- 
Cheers!
Rick

[Doxygen-develop] Implementing Doxygen enhancements

[Augusto J. D. <au...@ic...>]

Hello all,

I'm working on a documentation project (C library) and I'd like to
implement some enhancements in Doxygen:

a) alphabetical order of functions in modules (currently it seems that
Doxygen uses the processing order as it parses the C files);

b) a configuration option to indicate how to render [in], [out] and
[in/out] parameters in LaTeX (currently Doxygen uses $\leftarrow$,
$\rightarrow$ and $\leftrightarrow$, but my `customer' would rather have
the same rendering as in HTML;

c) a configuration option to disable the Modules tab in HTML output.


As this is the first time I'd be working on Doxygen's code, I'd like to
know if there's anything special I should be aware of. Should I discuss
in the list the specifications for the three enhancements I'm planning?
Which `diff' parameters should I use when submitting a patch? And is
this the right list to discuss these matters? :)


Thanks in advance,
Cheers,

-- 
Augusto Jun Devegili
http://devegili.org

Code is poetry

Re: [Doxygen-develop] feature request: utf encoding

[Hyunwoo P. <par...@dg...>]

Hi. :)

I also have same problem.
so, I added one more language, "english.utf8" for utf8 with attached patch file.

in doxyfile config, "OUTPUT_LANGUAGE = english.utf8" will select the english and utf8 encoding.

I think it`s very easy to make another language such as korean.utf8, french.utf8, ..., like this manner.

Regards.
Hyunwoo Park.


Peter Münster 쓴 글:
> On Sun, 26 Nov 2006, Peter Münster wrote:
> 
>> On Sat, 25 Nov 2006, Jens Seidel wrote:
>>
>>> Using UTF-8 per default would also allow to drop the stupid Use Windows
>>> encoding option in the config file.
>> Or even better: instead of
>> USE_WINDOWS_ENCODING = yes/no
>> something like
>> USE_ENCODING = utf-8/iso-8859-1/iso-8859-15/etc. (default = utf-8)
> 
> Hello and happy new year!
> 
> I've just seen, that there are already such requests in the bugzilla
> database (numbers 150916, 159291 and 330109).
> 
> Is there perhaps already a developer working on this?
> 
> Cheers, Peter
> 

[Doxygen-develop] Fwd: Extending Doxygen to support other languages?

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

---------- Forwarded message ----------
From: Jason McKesson <ko...@gm...>
Date: Jan 11, 2007 12:38 PM
Subject: Re: [Doxygen-develop] Extending Doxygen to support other languages?
To: Chris Croughton <do...@ke...>


On 1/11/07, Chris Croughton <do...@ke...> wrote:
> On Wed, Jan 10, 2007 at 09:45:53PM -0800, Jason McKesson wrote:
>
> > 2: Replace the refactored objects in the document generation code.
> > Preferably, generate a single XML file that can be processed by XML
> > tools (whether C++ applications or XSLT transforms) that represents this
> > data, which is used as the source for generating all other formats.
>
> That's the bit I'm interested in, if we have an XML output which
> contains everything we need then we can easily (relatively, at least)
> produce man pages, TexInfo (FSF/GNU), HTML, TeX, RTF or anything else
> from it, in formats which match whatever we need (to meet
> company-imposed documentation standards, for instance).

It's actually fairly complete now (there are some improvements that
will be made, but it's functional). My issue at present is getting a
more recent version of Doxygen (my changes work against 1.4.7), and
working out how to build an appropriate patch/diff/etc file that I can
submit to the developers for inclusion.

The only issue that might be taken with it's inclusion, besides
deprecating the old XML format, is the fact that I included TinyXML.
It has a GPL-compatible license, like the other libraries Doxygen
uses, but it is an additional dependency. Of course, as the name
indicates, it's a very small library.

Re: [Doxygen-develop] Extending Doxygen to support other languages?

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

On Wed, Jan 10, 2007 at 09:45:53PM -0800, Jason McKesson wrote:

> 2: Replace the refactored objects in the document generation code. 
> Preferably, generate a single XML file that can be processed by XML 
> tools (whether C++ applications or XSLT transforms) that represents this 
> data, which is used as the source for generating all other formats.

That's the bit I'm interested in, if we have an XML output which
contains everything we need then we can easily (relatively, at least)
produce man pages, TexInfo (FSF/GNU), HTML, TeX, RTF or anything else
from it, in formats which match whatever we need (to meet
company-imposed documentation standards, for instance).

> To be honest, I could do steps 1 & 2. Indeed, I had to do some of that 
> in order to be able to talk to Doxygen in a reasonably coherent way. 1 & 
> 2 would be somewhat straightforward. And I would certainly be willing to 
> supply XSLTs for generating various kinds of output formats. HTML and 
> XSL-FO would be my personal specialties, but they probably wouldn't look 
> very "Doxygen style".

I would be very interested in your steps 1 and 2.  I did some hacking of
the man page generator quite a time ago, and it was painful trying to
work out where everything was.  Not that I'm all that familiar with XSLT
yet but it is at least a standard transform.  I tried to do a converter
from the existing (not yours) XML output to TexInfo but some of the
information was either not there or not sensibly accessible.

> Step 3 would require far more familiarity with how the parser builds the 
> documented code than I have or want. And steps 4-6 are well outside of 
> my league.

Like you I dont know the parser, my brief looks at it have been not
promising.  But I also don't need the parser to do much more than it
already does (I don't need it for other languages, for instance) so I
don't have the motivation to go into it in depth.

Chris C

Re: [Doxygen-develop] Extending Doxygen to support other languages?

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

I'm all for modularizing Doxygen. However, the hard part of Doxygen has 
always been the parsing/data collection. Compared to that, my XML 
documentation format is pretty simple stuff. Unless there is a concerted 
effort by people with Doxygen experience to refactor the project into 
something more modular, then ideas like this will remain ideas rather 
than fact.

Basically, given my rather limited experience with Doxygen, I believe 
that the following sequence of steps would need to be taken to make 
Doxygen a modular system for documenting code:

1: Refactor the internal data structures that hold the parsed 
documentation. This kind of refactoring is actually quite do-able 
without hurting the code too much. Basically, you need to write wrapper 
objects (much like the ones I used for my XML stuff) that reflect how we 
want to interface with the documentation rather than how Doxygen 
currently works now.

2: Replace the refactored objects in the document generation code. 
Preferably, generate a single XML file that can be processed by XML 
tools (whether C++ applications or XSLT transforms) that represents this 
data, which is used as the source for generating all other formats.

3: Remove the old objects. This means that, rather than the refactored 
objects being interfaces to the old data, they now are the only means of 
talking to the parsed data. So now the parsing code needs to use the 
refactored objects.

4: Refactor the parser. Much like the above, make a new kind of parser 
that, for the time being, acts as an interface with the old parser. If 
you're wondering why it is that this wasn't #1, it's because quite a bit 
of parsing actually happens in the documentation generators. Until those 
get straightened out, you can't modularize the parser. The interface 
will need to be able to be modular.

5: Given the new parser interface, the code that uses the parser will 
have to be substantially restructured/rewritten to use that new 
interface, much like step 2.

6: Kill off the old parser. Make the new parser interface a living, 
modularized parser interface that can have new pieces loaded from 
dynamic libraries and so forth.

To be honest, I could do steps 1 & 2. Indeed, I had to do some of that 
in order to be able to talk to Doxygen in a reasonably coherent way. 1 & 
2 would be somewhat straightforward. And I would certainly be willing to 
supply XSLTs for generating various kinds of output formats. HTML and 
XSL-FO would be my personal specialties, but they probably wouldn't look 
very "Doxygen style".

Step 3 would require far more familiarity with how the parser builds the 
documented code than I have or want. And steps 4-6 are well outside of 
my league.


Keith J Outwater wrote:
> Hello,
> I have seen this topic covered a few times in the archives, but there does 
> not seem to be a lot of activity in this area.
> I am very interested in using Doxygen to generate documentation for VHDL 
> and other file types such as shell scripts, makefiles and the like.
> Seems to me that moving to modular architecture for Doxygen would be a big 
> enabler for those interested in having multi-language support.  For 
> example, a plugin architecture that would allow development of language 
> specific front ends that would produce language-neutral data for the 
> Doxygen core to process.  Back end plugins could then format this 
> information.
> I am more that willing to work on a VHDL front-end (plugin), but, sadly, 
> my time and skills are probably not up to the task of helping re-architect 
> Doxygen!
> Is such an approach feasible?
>
> Keith
>
> -------------------------------------------------------------------------
> 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
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>
>   

[Doxygen-develop] Extending Doxygen to support other languages?

[Keith J O. <kjo...@ra...>]

Hello,
I have seen this topic covered a few times in the archives, but there does 
not seem to be a lot of activity in this area.
I am very interested in using Doxygen to generate documentation for VHDL 
and other file types such as shell scripts, makefiles and the like.
Seems to me that moving to modular architecture for Doxygen would be a big 
enabler for those interested in having multi-language support.  For 
example, a plugin architecture that would allow development of language 
specific front ends that would produce language-neutral data for the 
Doxygen core to process.  Back end plugins could then format this 
information.
I am more that willing to work on a VHDL front-end (plugin), but, sadly, 
my time and skills are probably not up to the task of helping re-architect 
Doxygen!
Is such an approach feasible?

Keith

[Doxygen-develop] Constant string problem in c#

[Paul V. <ve...@cd...>]

Hello,

One more information: The warning appear in the next function header

Regards.

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.8/621 - Release Date: 09.01.2007
13:37
 

[Doxygen-develop] Constant string problem in c#

[Paul V. <ve...@cd...>]

Hello,

In
	m_CfgURL = m_CfgURL.Replace(@"\\", @"\");

@"\" sting constant drive to a "xxxx.cs:1138: Warning: member with no name
found."

There is no warning with @"\\", but only with @"\"

Regards.

------------------------------
Paul Veuve
ve...@cd...
------------------------------
CDI CONSEILS ET DEVELOPPEMENTS
INDUSTRIELS SA
Chemin de la Justice 15
CH-2000 NEUCHATEL
------------------------------
http://www.cdisa.ch

Phone  (+41 32) 733 31 31 
   or  (+41 78) 600 31 31

  Fax  (+41 32) 733 31 32
------------------------------

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.7/620 - Release Date: 08.01.2007
16:12
 

[Doxygen-develop] Doxygen oddity: Enum Handling

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

As anyone who has bothered to spend any time in the Doxygen codebase can 
attest to, it is in serious need of refactoring. As I am spending quite 
a bit of time in that code, I figured it would be helpful to document 
some of the oddities about how Doxygen behaves, just in case anyone 
decides to go through and attempt to correct them.

The one I've most recently found involves how enumerations are handled. 
If an enumeration is found in a class, it is actually handled slightly 
differently from if it is found in a namespace. In a class, the members 
of the enumeration are stored in both the enumeration MemberDef, as well 
as direct children of the ClassDef itself. For NamespaceDefs, only the 
enumeration MemberDef has enumeration members. So if you expect to see 
enum values in the list of NamespaceDef members, you're going to find 
yourself disappointed.

Re: [Doxygen-develop] feature request: utf encoding

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

On Sun, 26 Nov 2006, Peter M=FCnster wrote:

> On Sat, 25 Nov 2006, Jens Seidel wrote:
>=20
> > Using UTF-8 per default would also allow to drop the stupid Use W=
indows
> > encoding option in the config file.
>=20
> Or even better: instead of
> USE_WINDOWS_ENCODING =3D yes/no
> something like
> USE_ENCODING =3D utf-8/iso-8859-1/iso-8859-15/etc. (default =3D utf=
-8)

Hello and happy new year!

I've just seen, that there are already such requests in the bugzilla
database (numbers 150916, 159291 and 330109).

Is there perhaps already a developer working on this?

Cheers, Peter

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

[Doxygen-develop] Global namespace

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

Not sure if this got through the last time.

I have been wrestling with a problem with Doxygen's innards for some
time now, and I need some guidance. The problem is this.

I'm attempting to shoehorn a global namespace (that is, the list of
members and member groups that is not part of any namespace) into my XML
Doxygen output format. My initial attempt at creating a global namespace
was to assume that all member groups and ungrouped members of all
FileDefs were, by definition, global. I thought this seemed pretty
reasonable.

The problem is this: whenever I create a member group in a namespace
that is itself global (ie, the first child of the global namespace),
Doxygen decides that there are actually two member groups: one that
lives in the NamespaceDef and one that lives in the FileDef. This
wouldn't be so bad if member groups were treated as first-class objects
in Doxygen (the way Definitions are); in that case, I could simply ask
the member group for its owning scope and check to see if this is the
global namespace or not.

The kinda strange part is that, as I just mentioned, Doxygen does have a
namespace variable that it does call the "global" namespace. Too bad it
doesn't store MemberDefs and member groups that are global; it only
stores ClassDefs and NamespaceDefs.

So, what I need is one of the following. The best-case obviously would
be to have a real global namespace object in Doxygen. I suspect this
isn't going to happen, due to the quantity of legacy code in Doxygen.
Pretty much every output formatter would need to change.

Another would be for member groups to be treated as first-class objects,
such that if two Definitions share them, then they are sharing the same
member group pointer, and the member group would derive from Definition
like everything else. And member groups can access their owning scopes.
For the same reason as above, I won't hold my breath.

Which brings me to the last possibility: hackery. I need an algorithm
that uniquely generates member groups that are in the global namespace.
Basically, I need to be able to take a member group and ask it if it
lives in a namespace already. I see no immediately obvious way of doing
so given simply a member group. Is there some way to resolve this issue?

[Doxygen-develop] Global namespace

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

I have been wrestling with a problem with Doxygen's innards for some 
time now, and I need some guidance. The problem is this.

I'm attempting to shoehorn a global namespace (that is, the list of 
members and member groups that is not part of any namespace) into my XML 
Doxygen output format. My initial attempt at creating a global namespace 
was to assume that all member groups and ungrouped members of all 
FileDefs were, by definition, global. I thought this seemed pretty 
reasonable.

The problem is this: whenever I create a member group in a namespace 
that is itself global (ie, the first child of the global namespace), 
Doxygen decides that there are actually two member groups: one that 
lives in the NamespaceDef and one that lives in the FileDef. This 
wouldn't be so bad if member groups were treated as first-class objects 
in Doxygen (the way Definitions are); in that case, I could simply ask 
the member group for its owning scope and check to see if this is the 
global namespace or not.

The kinda strange part is that, as I just mentioned, Doxygen does have a 
namespace variable that it does call the "global" namespace. Too bad it 
doesn't store MemberDefs and member groups that are global; it only 
stores ClassDefs and NamespaceDefs.

So, what I need is one of the following. The best-case obviously would 
be to have a real global namespace object in Doxygen. I suspect this 
isn't going to happen, due to the quantity of legacy code in Doxygen. 
Pretty much every output formatter would need to change.

Another would be for member groups to be treated as first-class objects, 
such that if two Definitions share them, then they are sharing the same 
member group pointer, and the member group would derive from Definition 
like everything else. And member groups can access their owning scopes. 
For the same reason as above, I won't hold my breath.

Which brings me to the last possibility: hackery. I need an algorithm 
that uniquely generates member groups that are in the global namespace. 
Basically, I need to be able to take a member group and ask it if it 
lives in a namespace already. I see no immediately obvious way of doing 
so given simply a member group. Is there some way to resolve this issue?

[Doxygen-develop] linking to sourceline

[Anton H. <ant...@bi...>]

Hi

I wish to add an Html Info with problem reports that will point to the 
sourcelines. How can i do this!

I have filename with path and linenumber, but i did not know how the doxygen
filename is generated.

my goal is to add an report of codingstyle issues to the doxygen api report

anton 

[Doxygen-develop] Extending architecture documentation

[William H. <ho...@ui...>]

As part of a class project, I've been working on extending the existing doxygen architecture information.  I wanted to let people know about what I've been doing to get feedback and see if I should put together a patch of the changes/additions I've done.

I added an optional install step in the manual that talks about running doxygen on itself, and updated the current "internals" page to reference the developer documentation.  I don't have these changes online, but mention them to help provide context.

Then I integrated the existing documentation into the Doxyfile that builds the documentation for doxygen, adding additional links, making some corrections, and elaborating on some points.  So in my processed html files (based on 9-December version in CVS, with the html files available at http://netfiles.uiuc.edu/horn/www/doxygen) the architecture diagram is on the main page, and I moved the details off to separate pages, which are now cross-linked to the doxygen files and classes.

I also updated the documentation for a few classes (like BufStr), but that was taking a while, so I concentrated more on starting to provide file-level comments (the file list is starting to have more details).  I also moved some doxygen comments from lex files into header files, since the .cpp files generated from the lex files are not scanned by the current Doxyfile.

I'm still working on revising some of the content (and adding more content), and the goals of my project for my class may not be quite the same as what is needed/helpful to the doxygen community.  But I'm certainly willing to figure out how to use patch to submit the modifications if there is any interest.

And feel free to provide any feedback.

Thanks,
William Horn