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

Re: [Doxygen-develop] 1.5.5 and Fortran

[Oleg B. <og...@gm...>]

Hi,

> I try to use doxygen 1.5.5 (svn 612 ) with my fortran project.
> Unfortunately I get the following error
>
> Preprocessing C:/Users/Alin M Elena/tdtbuj/source/Constants.f90...
> Parsing file C:/Users/Alin M Elena/tdtbuj/source/Constants.f90...
> parse error in end
> <scopename>********************************************************************
>  Error in file C:/Users/Alin M Elena/tdtbuj/source/Constants.f90 line: 185,
> state: 4
I tried SVN version several days ago and it did not work for me
either. Unfortunately, I do not have time to look into it.

I think I'll have some time next week to fix this and look through
some issues in bugzilla.

Oleg

[Doxygen-develop] Doxygen 1.5.5 breaks partial include paths

[Tim N. <nie...@kb...>]

Hello Doxygen devs.

We have a source tree which has another project inside. Within this
project tree again includes of the form <extproject/dir/file.h> relative
to this projects root. With doxygen 1.5.5 this breaks, astonishingly
only for a few files and not all (which probably has something to do
with the caching but I can't tell).

What I can tell is that the problem is related to src/util.cpp line 4472.

There fdStripPath is compared to pathStripped. Our strip paths are empty
so nothing actually happens to the paths. But pathStripped contains the
relative path very similar to the include mentioned above. For that
include it would be "extproject/dir". But fdStripPath (is the absolute
path, for example something like "/home/tim/project1/extproject/dir".
The comparison now obviously fails and the file is not found.

To fix this I modified line 4471 to read:
QCString fdStripPath =
stripFromIncludePath(fd->getPath().right(path.length()));

".right(...)" has been added to take only part of the path which has the
same length as the path we compare against effectively using only the
relative path. This is more similar to what it used to be in 1.5.4.

Also I noticed that before the upgrade we could have in the .cpp:
using namespace std;
void myfunc(string foo)

This will complain now that it should have been
void myfunc(std::string foo)
which is obviously superfluous here. Is that a regression or the path to
proper namespace handling?

Regards from Aachen,
	Tim

-- 
Tim Niemueller                      KBSG - Knowledge-Based Systems Group
========================================================================
AllemaniACs RoboCup Team                          RWTH Aachen University
http://robocup.rwth-aachen.de                            Ahornstrasse 55
http://www.kbsg.rwth-aachen.de                            D-52056 Aachen

[Doxygen-develop] Failed compilation on OS X (10.4.11)

[Jan R. <jan...@co...>]

Hi all

The doxygen-1.5.5 fails to compile on OS X 10.4.11.

qfiledefs_p.h:258: error: field 'st' has incomplete type
{standard input}:unknown:FATAL:can't create output file: ../objects/qfile.o
make[1]: *** [../objects/qfile.o] Error 1
make: *** [all] Error 2

Source was taken from doxygen-1.5.5.src.tar.gz.

Cause seems to be failure to include <sys/stat.h> in qtools/qfiledefs_p.h

Attached patch allows MAC_OS_X_VERSION_10_4 to include  <sys/stat.h> as it
is done for MAC_OS_X_VERSION_10_5.
I don't know if that is correct fix, because there is some definition of
_OS_UNIX_ in the same block.

Jan

[Doxygen-develop] Matlab frontend

[Ivo C. <iv...@ya...>]

After reading through the mailing list seeking for a
matlab frontend to doxygen I encountered some related
messages, unfortunately these are from 2 years back.

Is there any progress in a matlab frontend ? As
currently tools are quite lacking in generating good
dependencies and html output for matlab (with support
for matlab's pseudo classes and inheritance.)

Is adapting Octave's lexer and parser files a
possibility. Shouldn't be too hard I think, except for
converting the structure into Doxygen's C++ class
tree.

kind regards,
ilm




      __________________________________________________________
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

[Doxygen-develop] about the errors and warnings...

[PY <ek...@gm...>]

Hi all,

I have another issue with my documentation: I would like to classify the 
errors (like warning, serious, critical) and present it in a display.. 
the log is just plain txt.. there is also some xml output available?

thanks in advance for any help,

Pablo

Re: [Doxygen-develop] Interest in new XML format for Doxygen export

[Ted D. <ted...@jp...>]

Sorry - I'm still here an interested.  We're just in the middle of a
critical delivery so I haven't had to time to get to it.  I should have time
at the end of this week or early next week to update the patches.

> -----Original Message-----
> From: dox...@li... [mailto:doxygen-
> dev...@li...] On Behalf Of Jason McKesson
> Sent: Monday, January 21, 2008 10:06 PM
> To: Pablo Yamamoto
> Cc: dox...@li...
> Subject: Re: [Doxygen-develop] Interest in new XML format for Doxygen
> export
> 
> Well, as much as I would like to, there's not much I can do to help. I
> can't build Doxygen, so I can't update from my current version to one
> that I could produce a patch for and submit it. I gave the code to Ted
> Drain, who seemed interested in making a proper patch for Doxygen, but
> I
> haven't heard back from him about it.
> 
> And the current XML is just not appropriate for any reasonable
> conversion process. You can turn it into something that looks like the
> current Doxygen documentation, but you would never be able to do
> anything freeform with it. Not through XSLT alone.
> 
> Pablo Yamamoto wrote:
> > Hi all,
> >
> > I came across to this thread since we have tons of doxygen HTML
> documentation and we want to integrate it with other documents. We are
> introducing DITA in our system and a clearly structured doxygen-XML
> would be the right starting point.
> >
> > I don't know how long it would take to get the new doxygen XML format
> but I am positively interesting in producing deliverables very soon,
> and some other DITA-colleagues as well, so if anyone else is working
> also on that we could join forces to develop some stylesheet to process
> the current XML.
> >
> > Best Regards,
> >
> > Pablo
> >
> > ---------------------------------------------------------------------
> ----
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Doxygen-develop mailing list
> > Dox...@li...
> > https://lists.sourceforge.net/lists/listinfo/doxygen-develop
> >
> >
> 
> 
> -----------------------------------------------------------------------
> --
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

Re: [Doxygen-develop] Interest in new XML format for Doxygen export

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

Well, as much as I would like to, there's not much I can do to help. I 
can't build Doxygen, so I can't update from my current version to one 
that I could produce a patch for and submit it. I gave the code to Ted 
Drain, who seemed interested in making a proper patch for Doxygen, but I 
haven't heard back from him about it.

And the current XML is just not appropriate for any reasonable 
conversion process. You can turn it into something that looks like the 
current Doxygen documentation, but you would never be able to do 
anything freeform with it. Not through XSLT alone.

Pablo Yamamoto wrote:
> Hi all,
>
> I came across to this thread since we have tons of doxygen HTML documentation and we want to integrate it with other documents. We are introducing DITA in our system and a clearly structured doxygen-XML would be the right starting point.
>
> I don't know how long it would take to get the new doxygen XML format but I am positively interesting in producing deliverables very soon, and some other DITA-colleagues as well, so if anyone else is working also on that we could join forces to develop some stylesheet to process the current XML.
>
> Best Regards,
>
> Pablo
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>
>   

Re: [Doxygen-develop] Interest in new XML format for Doxygen export

[Pablo Y. <Ek...@gm...>]

Hi all,

I came across to this thread since we have tons of doxygen HTML documentation and we want to integrate it with other documents. We are introducing DITA in our system and a clearly structured doxygen-XML would be the right starting point.

I don't know how long it would take to get the new doxygen XML format but I am positively interesting in producing deliverables very soon, and some other DITA-colleagues as well, so if anyone else is working also on that we could join forces to develop some stylesheet to process the current XML.

Best Regards,

Pablo

[Doxygen-develop] Doxygen git repo

[Bryon R. <ka...@ka...>]

Hello all, I have a bugfix IRT python support in doxygen, in the gnome
Bugzilla, #331674, and since it appears that the svn repo is taking
forever to come back up, would it be helpful to put a git server
online?  I have a host and disk I can provide this on.  For the moment
I'm building a repo of the released versions from the stack.nl FTP.  If
anyone has a git-svn or svk mirror they could share with me to build a
better history, that would be handy.  Would this be useful?

/B
-- 
--
Fhcre Fcl
<ka...@ka...>
FE0D EC23 6464 726A CD54  48D3 04AD 86FE 6878 ABD5

Re: [Doxygen-develop] Perl/Sh parser

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

Hi Nigel,

On 9 jan 2008, at 01:03, Nigel Pearson wrote:

>
> Hi guys. Happy new year!
>
>
> I am one of the MythTV developers, and some
> of us use Doxygen in the project a lot.
> The MythTV source code has C, C++, Obj-C,
> plus a contrib directory with the usual
> assortment of Perl, Shell and Python scripts.
>
> I'm also a Perl hacker from way-back,
> and used to use a simple inhouse tool
> to generate manpages and HTML from custom
> markup in our Perl and Shell scripts.
> (this was in the days before POD)
>
>
> So, I would like to start adding Perl/Sh parsing.
> I am lumping these together because they have
> similar comment parsing requirements,
> and I am hoping that one parser can do both.
> A few questions to help give me direction:
>
>
> 1) How do we feel about adding a parser
> that just summarises a language
> instead of trying to parse every little
> feature that they have crammed in there?
> (e.g. subroutines and markup instead of
>      full OO, type matching, blessed modules)

You typically need to be able to parse every little detail in order
to create a summary (and ignore the rest). This is especially true for  
scripts and perl,
where there does not need to be any structure (i.e. you can just
start with statements, outside of functions or classes).

>
> 2) I have little idea of where
> to start. The structure of the parsers
> is a little confusing - I can't work out
> how the stuff generated from pyscanner.l
> or fortranscanner.l is called, for example.
> Any relevant doco, discussion or advice?

Look at src/parserintf.h that is the main interface for
implementing new parsers. A parser is registered in initDoxygen, like so

Doxygen::parserManager->registerParser(".f90", new  
FortranLanguageScanner);

whenever doxygen find a file with the .f90 extension is will invoke  
the methods
of the FortranLanguageScanner to parse the file.

>
> 3) For a project like MythTV, I don't
> want symbols in the scripted stuff to
> be references to the compiled stuff.
> (e.g. if a Perl script has a usage() routine,
>      it is in no way related to a C function
>      which is also named usage() or _usage() )
> How does the PHP parser deal with this?

You typically do not make a doxygen project containing multiple  
languages,
so then this is not an issue.

Regards,
   Dimitri

[Doxygen-develop] Perl/Sh parser

[Nigel P. <ni...@in...>]

Hi guys. Happy new year!


I am one of the MythTV developers, and some
of us use Doxygen in the project a lot.
The MythTV source code has C, C++, Obj-C,
plus a contrib directory with the usual
assortment of Perl, Shell and Python scripts.

I'm also a Perl hacker from way-back,
and used to use a simple inhouse tool
to generate manpages and HTML from custom
markup in our Perl and Shell scripts.
(this was in the days before POD)


So, I would like to start adding Perl/Sh parsing.
I am lumping these together because they have
similar comment parsing requirements,
and I am hoping that one parser can do both.
A few questions to help give me direction:


1) How do we feel about adding a parser
that just summarises a language
instead of trying to parse every little
feature that they have crammed in there?
(e.g. subroutines and markup instead of
       full OO, type matching, blessed modules)


2) I have little idea of where
to start. The structure of the parsers
is a little confusing - I can't work out
how the stuff generated from pyscanner.l
or fortranscanner.l is called, for example.
Any relevant doco, discussion or advice?


3) For a project like MythTV, I don't
want symbols in the scripted stuff to
be references to the compiled stuff.
(e.g. if a Perl script has a usage() routine,
       it is in no way related to a C function
       which is also named usage() or _usage() )
How does the PHP parser deal with this?




Hacky first steps attached:

% diff -ru doxygen-1.5.4.orig doxygen-1.5.4 >doxy.perl.1.patch

--
Nigel Pearson, ni...@in...|"People say I'm strange,
Telstra Net. Eng., Sydney, Australia | does it make me a stranger?
Office: 9202 3900    Fax:  9261 3912 | My best friend was born...
Mobile: 0408 664435  Home: 9792 6998 |     in a manger"   -DC Talk

[Doxygen-develop] test

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

This is a test

Re: [Doxygen-develop] Interest in new XML format for Doxygen export

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

BTW, I've discovered something about how Doxygen does linking to 
typedefs. If you use a typedef in a parameter, Doxygen links to the 
actual type being referenced by the typedef. While this is probably very 
useful in the finished format, it isn't useful for an intermediate 
format. XML tools can easily determine what the final type being 
referenced is, but going backwards is impossible. Also, the XML format 
outputs references as replacement for the string that was being 
referenced, so if you use a typedef as an argument, it is basically 
impossible to find out what the actual typedef used is.

It would be good if Doxygen could preserve this information internally, 
at the level of DocVisitor. This would allow the individual 
DocVisitor-derived classes to decide among themselves how best to 
represent a link to a typedef, rather than forcing everyone to link to 
the final type.

Ted Drain wrote:
> Dimitri,
> I think the changes can be summarized like this:
>
> Doxygen outputs an XML schema that is mostly an XML representation of 
> the HTML documentation.  This means that for a given element (say a 
> function), the "data" (arguments, short description, long description, 
> etc) for that element is stored in several locations and sometimes the 
> same data is stored in multiple locations.
>
> I hope I'm not putting words in Jason's mouth but the here my take on 
> his changes:  The goal of the change is to make an XML schema that is 
> a representation of the data that doxygen has parsed and created, not 
> a representation of the HTML.  This would make it much easier to write 
> XML style sheets and applications to process this documentation into 
> different formats (like heavily customized HTML).
>
> We really need something like this because we're combining 
> documentation from user's guides, C++, and Python into a single 
> documentation repository that needs to have a common style for how the 
> various constructs are shown.  I think that a big part of the benefit 
> of this representation is that it makes all of the good things that 
> doxygen does more accessable.  It's difficult to dig through the 
> doxygen C++ data structures in order to make custom documents (and 
> it's hard to keep patches up to date, etc).  By having doxygen do the 
> parsing, grouping, cross-linking, etc and then outputting that in XML, 
> we can write stand-alone XML processing engines that do our 
> customization work without having to understand or change the doxygen 
> internals.
>
> Ted
>
> At 11:37 AM 12/16/2007, Dimitri van Heesch wrote:
>> Hi Jason,
>>
>> I'm interested in what you have been working on, so please tell us 
>> more about it.
>>
>> Building doxygen should not be a significant problem:
>> Doxygen does build with Studio 2005 (even with the free (as in beer) 
>> express version),
>> or with cygwin (or mingw), so it should not be a problem to get that 
>> working on your system.
>> If you have a patch against 1.5.1 that may already be useful.
>>
>> Regards,
>>   Dimitri
>>
>> On Dec 15, 2007 5:27 AM, Jason McKesson <ko...@gm... 
>> <mailto:ko...@gm...>> wrote:
>>
>>     I actually have this about 90% working (only a few of Doxygen
>>     features are not exported), and have had it around for some time.
>>     But there is a significant problem. Namely, that my changes are
>>     built against Doxygen 1.5.1, and the latest releases of Doxygen
>>     do not support Visual Studio 2003, which I use. If it uses a
>>     meta-build system like CMake or Premake that could export build
>>     files for virtually any development environment, then I could
>>     upgrade Doxygen and submit it as a patch.
>>

Re: [Doxygen-develop] bug? multi-line '///' comment incorrectly parsed in presence of '*/'

[Konstantin S. <kon...@gm...>]

doxygen is 1.5.4

On Dec 27, 2007 11:23 AM, Konstantin Serebryany <
kon...@gm...> wrote:

> Hi,
>
> If I have a two-line '///' comment which has '*/' in the second line, it
> is interpreted as comment terminator.
> Looks like a bug. Shall I file a bug report?
>
>
> Thanks,
>
> --kcc
>
>
> % ls
> Doxyfile  b.h
> % head *
> ==> Doxyfile <==
> INPUT=b.h
> PROJECT_NAME=FOO
> GENERATE_HTML=YES
> GENERATE_LATEX=NO
>
> ==> b.h <==
>   /// @file b.h
>
>   /// Two-line comment,
>   /// second line has misleading */ comment terminator.
>   void AAAAA();
> % doxygen > /dev/null 2>&1
> % lynx -dump html/b_8h.html
> ...
> Functions
>
>    comment terminator *void  [4]AAAAA ()
> ...
> Function Documentation
>
>    comment terminator* void AAAAA (  )
>
>    Two-line comment, second line has misleading
>
>

[Doxygen-develop] bug? multi-line '///' comment incorrectly parsed in presence of '*/'

[Konstantin S. <kon...@gm...>]

Hi,

If I have a two-line '///' comment which has '*/' in the second line, it is
interpreted as comment terminator.
Looks like a bug. Shall I file a bug report?


Thanks,

--kcc


% ls
Doxyfile  b.h
% head *
==> Doxyfile <==
INPUT=b.h
PROJECT_NAME=FOO
GENERATE_HTML=YES
GENERATE_LATEX=NO

==> b.h <==
  /// @file b.h

  /// Two-line comment,
  /// second line has misleading */ comment terminator.
  void AAAAA();
% doxygen > /dev/null 2>&1
% lynx -dump html/b_8h.html
...
Functions

   comment terminator *void  [4]AAAAA ()
...
Function Documentation

   comment terminator* void AAAAA (  )

   Two-line comment, second line has misleading

Re: [Doxygen-develop] Interest in new XML format for Doxygen export

[Ted D. <ted...@jp...>]

Dimitri,
I think the changes can be summarized like this:

Doxygen outputs an XML schema that is mostly an XML representation of 
the HTML documentation.  This means that for a given element (say a 
function), the "data" (arguments, short description, long 
description, etc) for that element is stored in several locations and 
sometimes the same data is stored in multiple locations.

I hope I'm not putting words in Jason's mouth but the here my take on 
his changes:  The goal of the change is to make an XML schema that is 
a representation of the data that doxygen has parsed and created, not 
a representation of the HTML.  This would make it much easier to 
write XML style sheets and applications to process this documentation 
into different formats (like heavily customized HTML).

We really need something like this because we're combining 
documentation from user's guides, C++, and Python into a single 
documentation repository that needs to have a common style for how 
the various constructs are shown.  I think that a big part of the 
benefit of this representation is that it makes all of the good 
things that doxygen does more accessable.  It's difficult to dig 
through the doxygen C++ data structures in order to make custom 
documents (and it's hard to keep patches up to date, etc).  By having 
doxygen do the parsing, grouping, cross-linking, etc and then 
outputting that in XML, we can write stand-alone XML processing 
engines that do our customization work without having to understand 
or change the doxygen internals.

Ted

At 11:37 AM 12/16/2007, Dimitri van Heesch wrote:
>Hi Jason,
>
>I'm interested in what you have been working on, so please tell us 
>more about it.
>
>Building doxygen should not be a significant problem:
>Doxygen does build with Studio 2005 (even with the free (as in beer) 
>express version),
>or with cygwin (or mingw), so it should not be a problem to get that 
>working on your system.
>If you have a patch against 1.5.1 that may already be useful.
>
>Regards,
>   Dimitri
>
>On Dec 15, 2007 5:27 AM, Jason McKesson 
><<mailto:ko...@gm...>ko...@gm...> wrote:
>I actually have this about 90% working (only a few of Doxygen 
>features are not exported), and have had it around for some time. 
>But there is a significant problem. Namely, that my changes are 
>built against Doxygen 1.5.1, and the latest releases of Doxygen do 
>not support Visual Studio 2003, which I use. If it uses a meta-build 
>system like CMake or Premake that could export build files for 
>virtually any development environment, then I could upgrade Doxygen 
>and submit it as a patch.
>
>
>Ted Drain wrote:
>>
>>Jason,
>>
>>I would love to see something like this included.  We use doxygen to
>>
>>create a reference manual for C++ software that's used by people
>>
>>through a Python interface.  It's a ton of work to munge the output
>>
>>documentation to something is Python-like that people can
>>
>>understand.  If we had a good XML format, this type of work could all
>>
>>be done through XSLT or XML processing.
>>
>>
>>Ted
>>
>>
>>Jason McKesson <mailto:korval2@gm...><korval2@gm...>:
>>
>>
>>>
>>>I am currently working on exporting a new XML format from Doxygen. I was
>>>
>>>wondering if there would be some interest in integrating this into the main
>>>
>>>line when it is finished.
>>>
>>>
>>>If you want more details about how this format differs from the current
>>>
>>>Doxygen XML format, please let me know.
>>>
>>>
>>
>>Ted Drain     Jet Propulsion 
>>Laboratory   <mailto:ted...@jp...>ted...@jp...
>>

Re: [Doxygen-develop] Interest in new XML format for Doxygen export

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

Hi Jason,

I'm interested in what you have been working on, so please tell us more
about it.

Building doxygen should not be a significant problem:
Doxygen does build with Studio 2005 (even with the free (as in beer) express
version),
or with cygwin (or mingw), so it should not be a problem to get that working
on your system.
If you have a patch against 1.5.1 that may already be useful.

Regards,
  Dimitri

On Dec 15, 2007 5:27 AM, Jason McKesson <ko...@gm...> wrote:

>  I actually have this about 90% working (only a few of Doxygen features
> are not exported), and have had it around for some time. But there is a
> significant problem. Namely, that my changes are built against Doxygen
> 1.5.1, and the latest releases of Doxygen do not support Visual Studio
> 2003, which I use. If it uses a meta-build system like CMake or Premake that
> could export build files for virtually any development environment, then I
> could upgrade Doxygen and submit it as a patch.
>
>
> Ted Drain wrote:
>
> Jason,
> I would love to see something like this included.  We use doxygen to
> create a reference manual for C++ software that's used by people
> through a Python interface.  It's a ton of work to munge the output
> documentation to something is Python-like that people can
> understand.  If we had a good XML format, this type of work could all
> be done through XSLT or XML processing.
>
> Ted
>
> Jason McKesson <korval2@gm...> <korval2@gm...>:
>
>
>  I am currently working on exporting a new XML format from Doxygen. I was
> wondering if there would be some interest in integrating this into the main
> line when it is finished.
>
> If you want more details about how this format differs from the current
> Doxygen XML format, please let me know.
>
>
>  Ted Drain     Jet Propulsion Laboratory   ted...@jp...
>
>

Re: [Doxygen-develop] Interest in new XML format for Doxygen export

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

I actually have this about 90% working (only a few of Doxygen features 
are not exported), and have had it around for some time. But there is a 
significant problem. Namely, that my changes are built against Doxygen 
1.5.1, and the latest releases of Doxygen do not support Visual Studio 
2003, which I use. If it uses a meta-build system like CMake or Premake 
that could export build files for virtually any development environment, 
then I could upgrade Doxygen and submit it as a patch.

Ted Drain wrote:
> Jason,
> I would love to see something like this included.  We use doxygen to 
> create a reference manual for C++ software that's used by people 
> through a Python interface.  It's a ton of work to munge the output 
> documentation to something is Python-like that people can 
> understand.  If we had a good XML format, this type of work could all 
> be done through XSLT or XML processing.
>
> Ted
>
> Jason McKesson <korval2@gm...>:
>   
>> I am currently working on exporting a new XML format from Doxygen. I was
>> wondering if there would be some interest in integrating this into the main
>> line when it is finished.
>>
>> If you want more details about how this format differs from the current
>> Doxygen XML format, please let me know.
>>     
>
> Ted Drain     Jet Propulsion Laboratory   ted...@jp...    
>
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>
>   

Re: [Doxygen-develop] Interest in new XML format for Doxygen export

[Ted D. <ted...@jp...>]

Jason,
I would love to see something like this included.  We use doxygen to 
create a reference manual for C++ software that's used by people 
through a Python interface.  It's a ton of work to munge the output 
documentation to something is Python-like that people can 
understand.  If we had a good XML format, this type of work could all 
be done through XSLT or XML processing.

Ted

Jason McKesson <korval2@gm...>:
>I am currently working on exporting a new XML format from Doxygen. I was
>wondering if there would be some interest in integrating this into the main
>line when it is finished.
>
>If you want more details about how this format differs from the current
>Doxygen XML format, please let me know.

Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

[Doxygen-develop] [Patch]: Added support for SVG graphics with dot

[Christian E. <ce...@gm...>]

Hello,

I've created a patch which adds support for generating Scaleable Vector Gr=
aphics instead 
of bitmaps (for HTML output).

Most today's browsers have at least limited support f=FCr rendering svg gr=
aphics. I got the 
best results with Opera, Konqueror is nearly Ok, Firefox has some work lef=
t...

SVG graphics are included with the <object></object> tag instead of <img>.=
 I got most 
information from SELFHTML (german only):

http://de.selfhtml.org/html/multimedia/objekte.htm#datendateien

For browsers which doens't support rendering SVG it's possible to show an =
alternative 
content (e.g. a png graphic). Thus my patch creates additional png (fixed)=
 graphics when 
the user selects svg.


Patch description (generated with 'svn diff'):
- config.l:
  o Added 'svg' item for DOT_IMAGE_FORMAT

- dot.h
  o Added prototype for getPngImageSize() (see open issues)

- dot.cpp
  o Implemented getPngImageSize() (see open issues)
  o Generate an additional png file if the user selected svg format
  o Include both files as mentioned in the above tutorial

- htmlvisitor.cpp:
  o Generate an additional png file if the user selected svg format
  o Include both files as mentioned in the above tutorial

I've tried to adopt the existing coding style as good as possible. There s=
hould be no 
additional changes than those mentioned above. If the user doesn't select =
the svg format, 
the patch shouldn't have any effects.


Open issues:
- Image size of the SVG graphics
It's not very straightforward to generate an svg file with the same image =
size compared to 
an equal bitmap file. For reasons I don't understand the dot tool uses dif=
ferent sizes for 
svg and png graphics. I've tried to change this by setting DPI to 96 in do=
t but the resulting 
graphic was not rendered correctly in most of my browsers.

So I've decided to get the destination size from the png file (which is al=
so created) and to 
scale the svg to this value. This possibly strange way produced the most a=
cceptable 
results.

- Hyperlinks in the SVG graphics
For resons I don't know (perhaps a bug), all hyperlinks in the doxygen gen=
erated dot files 
start with a '$' character. This char is also present in the generated map=
 file. I've never 
seen this before but it seems that it doesn't harm.
For svg graphics at least some browsers don't use the map file, they get i=
nformation about 
hyperlinks directly from the svg file. Dot also includes the $ from the do=
t file here. At least 
in this case, my browsers failed to follow the link until I removed the $ =
char. Maybe it 
would be the best to remove it at all.


regards
Christian

[Doxygen-develop] simple C++ class method signature parsing

[Rajinder Y. <raj...@ho...>]

Hi I am making a simple tool that reads a C++ header file to generate a =
mock class using only the method signature it finds.

If someone who is knowledgable of the source code could please help me =
out. I want to know what files I would need to grab from the project =
that would enable me to parse only for class method signatures?

Thanks,
Rajinder

Re: [Doxygen-develop] Patch against SVN trunk

[Brendon C. <br...@ch...>]

Hi Dimitri,

I submitted a bug (Though made a few mistakes in the process). There was
some problem with my internet connection and although i only submitted
once there are three consecutive bugs listed in the database for this
item. I have marked them as duplicates. Sorry about that.

Also when initially submitting the report, there was no space to attach
the patch file so i included it in the text. Turns out i was able to
attach it after the bug was created and have done so.

One last issue. It will not let me add PATCH as a keyword as described
on the bug reports page:
http://www.stack.nl/~dimitri/doxygen/trouble.html#bug_reports


The bug link can be found below:
http://bugzilla.gnome.org/show_bug.cgi?id=494519


Also do you want a changelog entry as text in the bug report or attach a
new file: changelog with just the applicable entry?

Sorry for the issues. I am not familiar with bugzilla or at least that
configuration of it and made a few blunders :-)

Thanks,
Brendon.

> Thanks for your patch.
> 
> I will look into it, but it would help me if you could also submit
> a bug report (with severity set to enhancement) with the changelog and
> attach the patch. That way I do not forget to include it.
> It also helps you, as you will be notified when the patch is included.
> 
> Regards,
>   Dimitri

Re: [Doxygen-develop] Patch against SVN trunk

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

Hi Brendon,

Thanks for your patch.

I will look into it, but it would help me if you could also submit
a bug report (with severity set to enhancement) with the changelog and
attach the patch. That way I do not forget to include it.
It also helps you, as you will be notified when the patch is included.

Regards,
  Dimitri

On 11/4/07, Brendon Costa <br...@ch...> wrote:
>
> Hi doxygen devs,
>
> I have attached a patch for Doxygen that provides some features
> described below. I was wondering if a doxygen dev could look over these
> changes and commit them to SVN if they find no problems with them?
>
> The patch was created simply with: svn diff > ../edoc.patch
>
> Please let me know if there are any problems with these changes or if
> you dont think they should be accepted into doxygen what i could change
> to allow that or why.
>
> If you need any more information about this patch please let me know.
> There is also a previous post of mine on doxygen-users (Wrong place for
> it i just realised) which describes a set of similar patches i made
> against doxygen ver 1.5.1. This has some examples as to what this patch
> achieves.
>
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=46CF99DC.70307%40christian.net&forum_name=doxygen-users
>
> The main purpose for it is so that doxygen can correctly parse files
> that are generated by EDoc++ and produce documentation that contains
> accurate and detailed information about exception propagation through
> C++ code in addition to its normal API documentation. However these
> patches are for functionality that is not specific to EDoc++.
>
> For more information on EDoc++ see:
> http://edoc.sourceforge.net/
>
> Thanks,
> Brendon.
>
>
>
> * Added DESTDIR install capability to build
>
> * Added function for comparing two types taking default template
> parameters into account (Not a perfect match but does a best effort
> match using text comparisons and data existing in doxygen).
>
> * Modified matchArgument2() to match function prototypes taking template
> types into acount.
>
> * Modified processing of input files to ocurr in the order specified in
> the configuration file instead of in alphabetical order. This allows the
> user to determine the order in which appended documentation ocurrs when
> a single funciton has multiple blocks of documentation by ensuring that
> the file which contains the documentation to be first is listed in the
> configuration file before a file whose documentation the user wishes to
> come afterwards.
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>
>
>

[Doxygen-develop] Patch against SVN trunk

[Brendon C. <br...@ch...>]

Hi doxygen devs,

I have attached a patch for Doxygen that provides some features
described below. I was wondering if a doxygen dev could look over these
changes and commit them to SVN if they find no problems with them?

The patch was created simply with: svn diff > ../edoc.patch

Please let me know if there are any problems with these changes or if
you dont think they should be accepted into doxygen what i could change
to allow that or why.

If you need any more information about this patch please let me know.
There is also a previous post of mine on doxygen-users (Wrong place for
it i just realised) which describes a set of similar patches i made
against doxygen ver 1.5.1. This has some examples as to what this patch
achieves.

http://sourceforge.net/mailarchive/forum.php?thread_name=46CF99DC.70307%40christian.net&forum_name=doxygen-users

The main purpose for it is so that doxygen can correctly parse files
that are generated by EDoc++ and produce documentation that contains
accurate and detailed information about exception propagation through
C++ code in addition to its normal API documentation. However these
patches are for functionality that is not specific to EDoc++.

For more information on EDoc++ see:
http://edoc.sourceforge.net/

Thanks,
Brendon.



* Added DESTDIR install capability to build

* Added function for comparing two types taking default template
parameters into account (Not a perfect match but does a best effort
match using text comparisons and data existing in doxygen).

* Modified matchArgument2() to match function prototypes taking template
types into acount.

* Modified processing of input files to ocurr in the order specified in
the configuration file instead of in alphabetical order. This allows the
user to determine the order in which appended documentation ocurrs when
a single funciton has multiple blocks of documentation by ensuring that
the file which contains the documentation to be first is listed in the
configuration file before a file whose documentation the user wishes to
come afterwards.

[Doxygen-develop] SSH Host Key Change: svn.planetsaphire.com

[Kevin M. <km...@pt...>]

Just a note to developers with developer access to Planet Saphire...

As part of routine maintenance, the keys on Planet Saphire's SVN Server
has been changed.  Attatched is the new public key for the server; use
'ssh-keygen -l' to verify the fingerprint against the SVN server when
connecting again.

If there are any problems connecting, please let me know.

- KJM