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

Re: [Doxygen-develop] Problem compiling Doxygen on Linux

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

Hi Albert,

On Aug 29, 2011, at 12:15 , Albert wrote:

> Dear all,
> 
> I have some problems compiling the newest doxygen code (version 775 from svn)
> on a redhat 5 system.
> 
> I get the following error message:
> g++ -c -pipe -fno-exceptions -fno-rtti -DYY_TYPEDEF_YY_SIZE_T
> -Dyy_size_t=int -D_LARGEFILE_SOURCE -Wall -W -fno-exceptions -O2
> -I../qtools -I../libmd5 -o ../objects/ce_lex.o ce_lex.cpp
> ce_lex.cpp:168: error: multiple types in one declaration
> ce_lex.cpp:168: error: declaration does not declare anything
> 
> When I look in the the ce_lex.cpp file I see:
> typedef unsigned int yy_size_t;
> 
> I think thgere is a problem with the -D flag as set in the compile line.
> The compiule line is generated from:
> ./src/libdoxygen.pro.in:TMAKE_CXXFLAGS += -DYY_TYPEDEF_YY_SIZE_T -Dyy_size_t=int
> 
> I have removed in my version the  -Dyy_size_t=int and than everything compiles.

I specifically added the -D stuff to work around a series of nasty warnings
that appeared in the generated code, because yy_size_t was typedef'ed as a size_t
and then compared against an int.

Apparently the flex version of RedHat 5 produces different output.
Can you tell me which version they ship? I'm using 2.5.35.

Regards,
  Dimitri

[Doxygen-develop] Problem compiling Doxygen on Linux

[Albert <alb...@gm...>]

Dear all,

I have some problems compiling the newest doxygen code (version 775 from svn)
on a redhat 5 system.

I get the following error message:
g++ -c -pipe -fno-exceptions -fno-rtti -DYY_TYPEDEF_YY_SIZE_T
-Dyy_size_t=int -D_LARGEFILE_SOURCE -Wall -W -fno-exceptions -O2
-I../qtools -I../libmd5 -o ../objects/ce_lex.o ce_lex.cpp
ce_lex.cpp:168: error: multiple types in one declaration
ce_lex.cpp:168: error: declaration does not declare anything

When I look in the the ce_lex.cpp file I see:
typedef unsigned int yy_size_t;

I think thgere is a problem with the -D flag as set in the compile line.
The compiule line is generated from:
./src/libdoxygen.pro.in:TMAKE_CXXFLAGS += -DYY_TYPEDEF_YY_SIZE_T -Dyy_size_t=int

I have removed in my version the  -Dyy_size_t=int and than everything compiles.

Best Regards,


Albert

[Doxygen-develop] Different behavior of Doxygen-1.7.5 with Fortran modules

[Davide C. <dc...@ar...>]

Hi, and thanks as always for the great work.

I noticed a couple of strange things in new doxygen version when parsing 
Fortran documentation.

The first is that now MODULEs generate classes and not namespaces as 
before, this is confirmed by looking at a svn diff at line 1757/1790

http://doxygen.svn.sourceforge.net/viewvc/doxygen/trunk/src/fortranscanner.l?r1=762&r2=766

Is there a reason for this? IMHO a Fortran module is closer to a 
namespace than to a class and it can itself contain many class 
definitions (in the sense of struct (TYPE), interface or f2003 classes), 
moreover I find it useful to have a separate module list under the 
namespace menu, although the word namespace may seem quite unusual for a 
Fortran programmer, but that's a different problem.

Could this issue be fixed, or treated with a configuration switch, if 
1.7.5 behavior is really desired by anybody?

The second strange behavior is that now the brief class documentation 
within a module seems to be always sorted in alphabetical order 
regardless of the settings of SORT_BRIEF_DOCS. In fact this is connected 
to the previous issue that a module is a class: if reverting in 
fortranscanner.l CLASS_SEC => NAMESPACE_SEC the module becomes a 
namespace and sorting is as expected.

Thank you for your attention, bye, Davide

-- 
============================= Davide Cesari ============================
Servizio IdroMeteoClima - ARPA Emilia Romagna
NWP modelling - Modellistica numerica previsionale
  Phone/Fax: +39 051525926/+39 0516497501
  E-mail:    dc...@ar...
  Home page: http://www.webalice.it/o.drofa/davide/
  Address:   ARPA-SIM, Viale Silvani 6, 40122 Bologna, Italy
========================================================================


This message has been scanned for malware by Websense. www.websense.com

Re: [Doxygen-develop] Doxygen regression tests

[Vladimir S. <Vla...@ac...>]

Oleg,

Thank you for hint. The scripts are really useful.

Best regards
Vladimir

From: Oleg Batrashev [mailto:og...@gm...]
Sent: Tuesday, August 16, 2011 9:54 PM
To: Simonov, Vladimir
Cc: dox...@li...
Subject: Re: [Doxygen-develop] Doxygen regression tests

Hi Vladimir,

As I know Dimitri uses some simple script for regression testing, but Im not sure how successful. See his message as of  March 14. in the following thread
http://comments.gmane.org/gmane.text.doxygen.devel/1109

Zip attachment is there, hope it helps,

Oleg
On Tue, Aug 16, 2011 at 2:37 PM, Vladimir Simonov <Vla...@ac...<mailto:Vla...@ac...>> wrote:
Hi all,

Does the project have some kind of regression tests?
I'd like to check my changes for regression before submitting patches.

Regards
Vladimir Simonov

------------------------------------------------------------------------------
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at:  http://p.sf.net/sfu/wandisco-dev2dev

_______________________________________________
Doxygen-develop mailing list
Dox...@li...<mailto:Dox...@li...>
https://lists.sourceforge.net/lists/listinfo/doxygen-develop

Re: [Doxygen-develop] Doxygen regression tests

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

Hi Vladimir,

As I know Dimitri uses some simple script for regression testing, but Im not
sure how successful. See his message as of  March 14. in the following
thread
http://comments.gmane.org/gmane.text.doxygen.devel/1109

Zip attachment is there, hope it helps,

Oleg

On Tue, Aug 16, 2011 at 2:37 PM, Vladimir Simonov <
Vla...@ac...> wrote:

> Hi all,****
>
> ** **
>
> Does the project have some kind of regression tests?****
>
> I'd like to check my changes for regression before submitting patches.****
>
> ** **
>
> Regards****
>
> Vladimir Simonov****
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>
>

[Doxygen-develop] Doxygen regression tests

[Vladimir S. <Vla...@ac...>]

Hi all,

Does the project have some kind of regression tests?
I'd like to check my changes for regression before submitting patches.

Regards
Vladimir Simonov

Re: [Doxygen-develop] SQLite store for entries generated by Doxygen

[Sam P. <the...@gm...>]

I got a script that uses mozillas dxr to create a sqlite database of
my code structures, and then another script to pull in the comments
relating to those code structures.
I would be very interested in using the same database scheme as you,
to make my tool more portable.



On Wed, Aug 10, 2011 at 7:45 AM, Dimitri Van Heesch <do...@gm...> wrote:
> Hi Tuxdna,
>
> Very interesting experiment you did!rur
>
> Since I'm also very interested in the performance, I just tried your build on my MacBook,
> running doxygen on its own sources (I first removed the printf's to avoid printing overhead).
>
> Taking the best time out of three subsequent runs (using 'time doxygen')
> gave 280 seconds "real" time for the patched version (release build),
> against only 27 seconds for the official 1.7.4 release!
>
> So it seems that due to disk caching and OS file caching the performance of seeking is
> not that bad after all. Or alternatively, the overhead of SQLite queries is rather significant.
>
> Can you reproduce my results? Do you think there is room for improvement?
>
> Regards,
>  Dimitri
>
> P.S. I noticed some more warnings while running the patched version on doxygen sources,
> so maybe there is still some information not stored or read back correctly.
>
> On Aug 10, 2011, at 10:37 , tuxdna wrote:
>
>> Hello!
>>
>> Please ignore my previous email titled "dox...@li...".
>> I sent it by mistake.
>>
>> Currently Doxygen stores all the entries that it generates onto a file
>> ( via src/marshall.cpp ), where it sequentially writes everything
>> onto the disk. This is very fast while writing. However it is going to
>> be slow while reading back random entries ( disk spinning too much ).
>> Please correct if I am wrong here. I haven't explored all the options
>> if already provided by Doxygen to make it fast.
>>
>> I have been working on an alternative store which uses SQLite3 [1].
>> I have a working version of the code hosted on github ( branch sqlitedb [2] ).
>> Please note this is my first attempt with modifications to Doxygen.
>>
>> I generated documentation using sqlitedb implementation ( of qtools/ folder ),
>> and also generated documentation with Doxygen 1.7.4 present on the system.
>>
>> This is what I found - the documentation was identical in both the cases
>> with two exceptions:
>> * Doxygen version string was different in both the outputs ( which is obvious )
>> * "struct" is termed as "class" ( I think it is due to some recent
>> changes in Doxygen itself )
>>
>> SQLite3 database that is generated is entry_store_s3.db
>>
>> Please do share your thoughts on this implementation.
>>
>> Thanks and regards,
>> /tuxdna
>>
>> [1] http://sqlite.org/index.html
>> [2] https://github.com/tuxdna/Doxygen/tree/sqlitedb
>> <Doxyfile.custom>------------------------------------------------------------------------------
>> uberSVN's rich system and user administration capabilities and model
>> configuration take the hassle out of deploying and managing Subversion and
>> the tools developers use with it. Learn more about uberSVN and get a free
>> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>> _______________________________________________
>> Doxygen-develop mailing list
>> Dox...@li...
>> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>



-- 
Thank you,

Sam Price
(707) 742-3726

Re: [Doxygen-develop] SQLite store for entries generated by Doxygen

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

Hi Tuxdna,

Very interesting experiment you did!

Since I'm also very interested in the performance, I just tried your build on my MacBook, 
running doxygen on its own sources (I first removed the printf's to avoid printing overhead). 

Taking the best time out of three subsequent runs (using 'time doxygen') 
gave 280 seconds "real" time for the patched version (release build), 
against only 27 seconds for the official 1.7.4 release! 

So it seems that due to disk caching and OS file caching the performance of seeking is 
not that bad after all. Or alternatively, the overhead of SQLite queries is rather significant.

Can you reproduce my results? Do you think there is room for improvement?

Regards,
  Dimitri

P.S. I noticed some more warnings while running the patched version on doxygen sources,
so maybe there is still some information not stored or read back correctly.

On Aug 10, 2011, at 10:37 , tuxdna wrote:

> Hello!
> 
> Please ignore my previous email titled "dox...@li...".
> I sent it by mistake.
> 
> Currently Doxygen stores all the entries that it generates onto a file
> ( via src/marshall.cpp ), where it sequentially writes everything
> onto the disk. This is very fast while writing. However it is going to
> be slow while reading back random entries ( disk spinning too much ).
> Please correct if I am wrong here. I haven't explored all the options
> if already provided by Doxygen to make it fast.
> 
> I have been working on an alternative store which uses SQLite3 [1].
> I have a working version of the code hosted on github ( branch sqlitedb [2] ).
> Please note this is my first attempt with modifications to Doxygen.
> 
> I generated documentation using sqlitedb implementation ( of qtools/ folder ),
> and also generated documentation with Doxygen 1.7.4 present on the system.
> 
> This is what I found - the documentation was identical in both the cases
> with two exceptions:
> * Doxygen version string was different in both the outputs ( which is obvious )
> * "struct" is termed as "class" ( I think it is due to some recent
> changes in Doxygen itself )
> 
> SQLite3 database that is generated is entry_store_s3.db
> 
> Please do share your thoughts on this implementation.
> 
> Thanks and regards,
> /tuxdna
> 
> [1] http://sqlite.org/index.html
> [2] https://github.com/tuxdna/Doxygen/tree/sqlitedb
> <Doxyfile.custom>------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model 
> configuration take the hassle out of deploying and managing Subversion and 
> the tools developers use with it. Learn more about uberSVN and get a free 
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] SQLite store for entries generated by Doxygen

[tuxdna <tu...@gm...>]

Hello!

Please ignore my previous email titled "dox...@li...".
I sent it by mistake.

Currently Doxygen stores all the entries that it generates onto a file
( via src/marshall.cpp ), where it sequentially writes everything
onto the disk. This is very fast while writing. However it is going to
be slow while reading back random entries ( disk spinning too much ).
Please correct if I am wrong here. I haven't explored all the options
if already provided by Doxygen to make it fast.

I have been working on an alternative store which uses SQLite3 [1].
I have a working version of the code hosted on github ( branch sqlitedb [2] ).
Please note this is my first attempt with modifications to Doxygen.

I generated documentation using sqlitedb implementation ( of qtools/ folder ),
and also generated documentation with Doxygen 1.7.4 present on the system.

This is what I found - the documentation was identical in both the cases
 with two exceptions:
 * Doxygen version string was different in both the outputs ( which is obvious )
 * "struct" is termed as "class" ( I think it is due to some recent
changes in Doxygen itself )

SQLite3 database that is generated is entry_store_s3.db

Please do share your thoughts on this implementation.

Thanks and regards,
/tuxdna

[1] http://sqlite.org/index.html
[2] https://github.com/tuxdna/Doxygen/tree/sqlitedb

[Doxygen-develop] doxygen-users@lists.sourceforge.net

[tuxdna <tu...@gm...>]

Hello!

Currently Doxygen stores all the entries that it generates onto a file
( via src/marshall.cpp ), where it sequentially writes everything
onto the disk. This is very fast while writing. However it is going to
be slow while reading back random entries ( disk spinning too much ).
Please correct if I am wrong here. I haven't explored all the options
if already provided by Doxygen to make it fast.

I have been working on an alternative store which uses SQLite3 [1].
I have a working version of the code hosted on github ( branch sqlitedb [2] ).
Please note this is my first attempt with modifications to Doxygen.

I generated documentation using sqlitedb implementation ( of qtools/ folder ),
and also generated documentation with Doxygen 1.7.4 present on the system.

This is what I found - the documentation was identical in both the cases
 with two exceptions:
 * Doxygen version string was different in both the outputs ( which is obvious )
 * "struct" is termed as "class" ( I think it is due to some recent
changes in Doxygen itself )

SQLite3 database that is generated is entry_store_s3.db

Please do share your thoughts on this implementation.

Thanks and regards,
/tuxdna

[1] http://sqlite.org/index.html
[2] https://github.com/tuxdna/Doxygen/tree/sqlitedb

[Doxygen-develop] Opensearch provider for doxygen docs

[Phil L. <phi...@sq...>]

Hi Dimitri,

Just wondering if everything was OK with my patch, or if you'd like me to
make changes?

Phil

---------- Forwarded message ----------
From: Phil Lello <phi...@sq...>
Date: 13 July 2011 23:29
Subject: Re: [Doxygen-develop] Opensearch provider for doxygen docs
To: Dimitri Van Heesch <do...@gm...>


Hi Dimitri,

I think that file (src/search_functions.h) came from a typo... nothing is
using it. I have a vague recollection it was incorrectly generated at one
point instead of search_functions_php.h

I deleted the file from my local copy, ran distclean, and built everything
OK without it, including a clean build of docs on a test project, so that
file isn't needed.

Best Wishes,

Phil


On 13 July 2011 14:52, Dimitri Van Heesch <do...@gm...> wrote:

> Hi Phil,
>
> Thanks for your patch.
>
> I still have to look into your patch in detail, but I observed something
> odd:
> the file src/search_functions.h file has size 0, was that intentional?
>
> $ tar tvf opensearch-patch-to-r767.tar
> -rw-r--r--  0 phil   phil        0 Jun 21 15:00 src/search_functions.h
> -rw-r--r--  0 phil   phil     4642 Jun 23 06:05 src/libdoxygen.t
> -rw-r--r--  0 phil   phil     9631 Jun 23 05:47 src/search_functions.php
> -rw-r--r--  0 phil   phil    11466 Jun 23 05:47 src/search_functions_php.h
> -rw-r--r--  0 phil   phil     3268 Jun 24 01:03 src/search_opensearch.php
> -rw-r--r--  0 phil   phil     5910 Jun 23 06:06 src/libdoxygen.pro.in
> -rw-r--r--  0 phil   phil   125024 Jun 24 00:59 src/htmlgen.cpp
> -rw-r--r--  0 phil   phil    54231 Jun 23 06:06 winbuild/Doxygen.vcproj
>
> Regards,
>  Dimitri
>
> On Jul 13, 2011, at 4:49 , Phil Lello wrote:
>
> > On 21 June 2011 17:10, Dimitri Van Heesch <do...@gm...> wrote:
> > Hi Phil,
> >
> > On Jun 21, 2011, at 4:13 , Phil Lello wrote:
> >
> > > Hi all,
> > >
> > > I have written a prototype implementation of an opensearch provider for
> doxygen, which allows a doxygen docset to be searched in Firefox (and
> possibly IE and others) via the browser quicksearch (top-right box on
> firefox). It could also be extended to allow AJAX-based 'live' searches with
> server-side searches.
> > >
> > > I've managed to get this to provide both generic search functionality,
> as well as implementing search suggestions. Initially this was via manual
> edits ('gross hacks') to the generated search.php. I'm currently rolling the
> changes I made to the default search.php into htmlgen.cpp and search.php,
> and hope to have something to share over the next few days.
> > >
> > > To reduce the 'gross hack' elements, I've been re-structuring the mix
> between HtmlGenerator::writeSearchPage() and am approaching a version where
> the run-time decisions in writeSearchPage are largely writing config, and
> most decisions are made at run time.
> > >
> > > To elegantly split functionality for 'normal' search results and
> 'opensearch' results/suggestions, it would be neatest to split search.php
> into several parts:
> > >
> > > - A config.php that holds the config settings(!) - mostly strings from
> 'theTranslator' or Config_getXXX()
> > > - A search-functions.php that holds common code
> > > - A search.php that includes config.php and search-functions.php, and
> is basically the HTML header & footer
> > > - An opensearch.php that takes care of the opensearch interface.
> > >
> > > Does anyone have any objections to this approach, or anticipate
> resistance from users?
> >
> > Sounds sensible. I'm interested in your changes.
> > From an end-user point of view there will be no visible changes other
> than the opensearch feature, right?
> >
> > Regards,
> >  Dimitri
> >
> >
> > Hi Dimitri,
> >
> > Yes, this version should be transparent. As I've renamed 2 files, a
> straight SVN diff won't apply to a fresh checkout, so I've created a tarball
> of my changed files instead.
> >
> > The affected files are:
> > A  +    src/search_functions.h
> > M       src/libdoxygen.t
> > D       src/search.php
> > D       src/search_php.h
> > A  +    src/search_functions.php
> > A       src/search_functions_php.h
> > A       src/search_opensearch.php
> > M       src/libdoxygen.pro.in
> > M       src/htmlgen.cpp
> > M       winbuild/Doxygen.vcproj
> >
> > To reduce the generated PHP code, I've moved some decision logic out into
> PHP, and the relevant config settings get generated. Hopefully this won't
> cause too much confusion.
> >
> > I've attempted to patch the non-gcc build files; as I'm in a pure Linux
> environment, I can't test them. I needed to rebuild libdoxygen before
> building doxygen proper, as the dependencies don't seem quite right - I've
> not attempted to fix that as I the svn checkin includes some of the
> generated files, and I didn't want to bloat my changeset.
> >
> > This should all be transparent to users, with the exception that if they
> use the browser option to add a search provider, doxygen docs will become
> searchable. A more powerful search suggestions feature would be nice to add
> at a later date, but as I've been working on different things for a few
> weeks, I thought it was best to submit now.
> >
> > Let me know how it looks (or if I've broken something!) - in firefox, it
> should just be a case of going to the search-engine list next to the
> quick-search box, and checking 'add'. Just in case it isn't obvious, this
> requires server-side searches in Doxyfile to work.
> >
> >
> > <opensearch-patch-to-r767.tar>
>
>

[Doxygen-develop] include with formatting question

[Joel S. <joe...@oa...>]

Hi,

I think I have made some progress on adding
a directive (to be named) that will include
a file in Doxygen markup.  Until this works,
I am using "includejoel" as the command.

But I have a question.  I think I need to
parse the file, rather than just insert its
text or parse it like source code like the
other include variants do.  I have this
currently in htmldocvisitor.cpp in visit:

     case DocInclude::IncJoel:
       {
       QFileInfo fi(inc->exampleFile());
       BufStr JoelBuf(fi.size()+4096);

       Doxygen::parserManager->getParser(inc->extension())
                             ->parseInput(inc->exampleFile(),
                                          JoelBuf.data(),
                                          NULL);
       }
       break;

My question is.. the NULL is supposed to be of type
"Entry *" but I don't know which Entry to use.

Where do I get it?  How do I ensure the parsed
file is hung off the main parsing structure OK?

Am I even on the right track? :-D

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joe...@OA...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

Re: [Doxygen-develop] Citations / Bibliography

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

Hi David,

On Jul 20, 2011, at 3:12 , David Munger wrote:

> I would like to implement a citation mechanism for bibliographic
> references. I plan to do it by adding:
> 
> 1. a CITE_SOURCE (string) option that could only be set to "bibtex"
> for now, but would allow for later extension;
> 2. a CITE_STYLE (string) option that could take the values "bynumber"
> or "byname"
> 3. a CITE_BIBFILES (list) option to list the .bib files we want parsed;
> 4. a \cite command to be used while documenting the code.
> 
> The \cite command would behave a little bit like like the \ref
> command, but would also list its arguments in a .aux file that would
> later be processed by bibtex itself (with a custom .bst file) to
> generate the list of references.
> 
> I am already doing this for my own purposes with the help of an
> external Python script and custom .bst files. I would just need to
> reimplement this in Doxygen.
> 
> Would that make any sense?

Yes, there are more people wanting this, see also
https://bugzilla.gnome.org/show_bug.cgi?id=503239
for more ideas/wishes.

So if you can help, that would be great!

Regards,
  Dimitri

[Doxygen-develop] Citations / Bibliography

[David M. <mu...@gm...>]

I would like to implement a citation mechanism for bibliographic
references. I plan to do it by adding:

1. a CITE_SOURCE (string) option that could only be set to "bibtex"
for now, but would allow for later extension;
2. a CITE_STYLE (string) option that could take the values "bynumber"
or "byname"
3. a CITE_BIBFILES (list) option to list the .bib files we want parsed;
4. a \cite command to be used while documenting the code.

The \cite command would behave a little bit like like the \ref
command, but would also list its arguments in a .aux file that would
later be processed by bibtex itself (with a custom .bst file) to
generate the list of references.

I am already doing this for my own purposes with the help of an
external Python script and custom .bst files. I would just need to
reimplement this in Doxygen.

Would that make any sense?

David

[Doxygen-develop] Support for MathJax extensions (patch)

[David M. <mu...@gm...>]

Hello,

This is my first patch, so I am not sure if this is the proper way to submit
it.
This adds support for MathJax extensions through the MATHJAX_EXTENSIONS
config option. For example, use:
MATHJAX_EXTENSIONS     = TeX/AMSmath TeX/AMSsymbols

Best regards,

David Munger

Re: [Doxygen-develop] DITA XML Output cxxAPIMap.dtd Missing

[<jon...@no...>]

Hi, Joel.

To build the doxygen generated DITA (or the qdoc generated DITA for that matter) you need to install the Cxx specialisation plug-in which can be downloaded from https://projects.developer.nokia.com/doxygen_dita/files/cxxapirefv0.7.0.zip. The Cxx plug-in depends on the apiref plug-in so you will need to install that also. It's available for download from the DITA OT website.

Instructions on how to install a plug-in are available on the DITA OT sourceforge site, http://dita-ot.sourceforge.net/dev_ref/useplugin.html.

That will produce a basic html build of your content. You will then want to create your own plug-in that contains the css etc. that you want to apply to the documentation.

Regards,
Jonathan.

-----Original Message-----
From: ext Joel Sherrill [mailto:joe...@OA...] 
Sent: 07 July 2011 19:55
To: Harrington Jonathan (Nokia-SD/London)
Cc: dox...@li...
Subject: DITA XML Output cxxAPIMap.dtd Missing

Hi,

I hope I am not wandering too far from Doxygen.
Using the Nokia patch, I now have generated DITA XML for RTEMS.  I placed it in a dita subdirectory next to the latex and html.
I have installed the dita-ot 1.5.3 and
can build its html help sample OK.

I took their ant file and copied it to the Doxygen dita output directory.  It runs along for a bit and then ends with this:

BUILD FAILED
/users/joel/doxygen/onlinedocs/doxygen/cpukit/dita/doxygen_html.xml:25: 
The following error occurred while executing this line:
/users/joel/doxygen/DITA-OT1.5.3/build.xml:27: The following error occurred while executing this line:
/users/joel/doxygen/DITA-OT1.5.3/build_preprocess.xml:30: Failed to run
pipeline: [DOTJ012F][FATAL] Failed to parse the input file 'RTEMS CPU Kit with SuperCore.ditamap' due to the following exception. This may indicate that a plug-in for your document type is missing. Please correct the input based on the following message from the XML parser: 
:/users/joel/doxygen/onlinedocs/doxygen/cpukit/dita/dtd/cxxAPIMap.dtd
(No such file or directory)

I think it is pretty clear the the Doxygen generated DITA XML expects to find a cxxAPIMap.dtd file.
Where does one get this set of DTDs?

I am assuming it is obvious once I have a kit of the DTD files where they go in the dita-ot.

Thanks in advance.

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joe...@OA...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

Re: [Doxygen-develop] Including files Into Doxygen Comments

[Albert <alb...@gm...>]

Hi Joel,

A small thought: Are these guides generated separately (i.e. one after
the other) ? In that case a \cond might work (together with Doxyfile's
where the relevant condition is set.note that it is possible to have
Doxyfile's include other Doxyfile's)

Albert

On Thu, Jul 7, 2011 at 22:18, Joel Sherrill <joe...@oa...> wrote:
> Hi,
>
> This is bordering on a user question,
> but I think I may end up having to
> implement this so here goes.
>
> I was looking for a way to have some
> documentation for a method in a separate
> file.  All of the various include and
> example commands I see assume they
> are adding some markup like verbatim
> or before and after.
>
> + @include - @code
> + @includelineno - ditto
> + @verbinclude - @verbatim
> + @htmlinclude - @htmlonly
>
> I'm looking at a use case for someone where
> they have multiple language bindings and
> generate Java, C, and C++ API guides but
> a significant portion of the text is shared.
> They have a custom post-processing to insert
> the external files into the generated output.
> It just feels wrong to post-process and seems
> like something Doxygen should just be able to do.
>
> Any thoughts on this?  I can't be the first
> person to think this was useful. :)
>
> If useful, what would be a good command name
> and existing comment to base it upon.
>
> --
> Joel Sherrill, Ph.D.             Director of Research&  Development
> joe...@OA...        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>

[Doxygen-develop] Including files Into Doxygen Comments

[Joel S. <joe...@oa...>]

Hi,

This is bordering on a user question,
but I think I may end up having to
implement this so here goes.

I was looking for a way to have some
documentation for a method in a separate
file.  All of the various include and
example commands I see assume they
are adding some markup like verbatim
or before and after.

+ @include - @code
+ @includelineno - ditto
+ @verbinclude - @verbatim
+ @htmlinclude - @htmlonly

I'm looking at a use case for someone where
they have multiple language bindings and
generate Java, C, and C++ API guides but
a significant portion of the text is shared.
They have a custom post-processing to insert
the external files into the generated output.
It just feels wrong to post-process and seems
like something Doxygen should just be able to do.

Any thoughts on this?  I can't be the first
person to think this was useful. :)

If useful, what would be a good command name
and existing comment to base it upon.

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joe...@OA...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

[Doxygen-develop] DITA XML Output cxxAPIMap.dtd Missing

[Joel S. <joe...@oa...>]

Hi,

I hope I am not wandering too far from Doxygen.
Using the Nokia patch, I now have generated
DITA XML for RTEMS.  I placed it in a dita
subdirectory next to the latex and html.
I have installed the dita-ot 1.5.3 and
can build its html help sample OK.

I took their ant file and copied it to the
Doxygen dita output directory.  It runs
along for a bit and then ends with this:

BUILD FAILED
/users/joel/doxygen/onlinedocs/doxygen/cpukit/dita/doxygen_html.xml:25: 
The following error occurred while executing this line:
/users/joel/doxygen/DITA-OT1.5.3/build.xml:27: The following error 
occurred while executing this line:
/users/joel/doxygen/DITA-OT1.5.3/build_preprocess.xml:30: Failed to run 
pipeline: [DOTJ012F][FATAL] Failed to parse the input file 'RTEMS CPU 
Kit with SuperCore.ditamap' due to the following exception. This may 
indicate that a plug-in for your document type is missing. Please 
correct the input based on the following message from the XML parser: 
:/users/joel/doxygen/onlinedocs/doxygen/cpukit/dita/dtd/cxxAPIMap.dtd 
(No such file or directory)

I think it is pretty clear the the Doxygen generated
DITA XML expects to find a cxxAPIMap.dtd file.
Where does one get this set of DTDs?

I am assuming it is obvious once I have a kit of
the DTD files where they go in the dita-ot.

Thanks in advance.

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joe...@OA...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

Re: [Doxygen-develop] DITA XML Support Status

[Joel S. <joe...@oa...>]

On 07/06/2011 09:28 AM, jon...@no... wrote:
> Hi, Joel.
>
> Latest patch and binaries now uploaded to https://projects.developer.nokia.com/doxygen_dita/files/.
>
>> When you say latest, do you mean svn or 1.7.4?
> Binaries were built against a svn checkout from today, but the patch should apply cleanly to the last stable doxygen release also.
>
>> Other that the obvious reports of success or details on problems, what type of feedback would you like?
> Where you think the format (dtd) could be improved, feature requests, bug reports etc.
>
>> It would be good to get this merged so it because more mainstream.
> I have created an "enhancement" on doxygens bugzilla and applied the patch so probably best to continue the conversation over there. The url is: https://bugzilla.gnome.org/show_bug.cgi?id=654087.
>
Thanks for the quick update but the patch doesn't build for me:

xmlditagen.cpp: In member function ‘QString 
DITAGeneratorBase::nameLookup(const MemberDef*) const’:
xmlditagen.cpp:1326:14: warning: unused variable ‘pN’
xmlditagen.cpp: In member function ‘void 
DITAFileGenerator::generateXMLForFile(FileDef*)’:
xmlditagen.cpp:2443:18: warning: unused variable ‘nd’
xmlditagen.cpp: At global scope:
xmlditagen.cpp:2593:6: warning: unused parameter ‘dl’
xmlditagen.cpp:2593:6: warning: unused parameter ‘xt’
xmlditagen.cpp:2638:6: warning: unused parameter ‘outDir’
xmlditagen.cpp: In function ‘void generateXML(QCString)’:
xmlditagen.cpp:2667:67: error: cannot pass objects of 
non-trivially-copyable type ‘class QString’ through ‘...’


I added a .data() to the use of QString ix and it compiles
now. I haven't looked at the warnings or used the
executable yet.
>> We try not to have quirky code in RTEMS but it wouldn't surprise me if someone else found it quirky.  We use a lot of static inline methods to encapsulate functionality in an OO style.
> I am sure the kernel engineers here would take exception to my use of the word "quirky" :), but I'm not as smart as those guys so some of it looks "quirky" to me.
>
:)
>> I am just getting started on this experiment.  Is there a good guide for the process of getting from Doxygen all the way to the Information Centre?
> None that I know off. Once you get doxygen outputting the dita xml running the DITA OT with our plug-in should get you most of the way there (DITA OT supports outputting as Eclipse jar files). We need to use 64bit java and give it a LOT of ram to get it to build all of Symbian OS so that might be something to watch out for.
>
OK. I will just beg for help and collect the resulting notes into a howto
so others have an easier path.
> Regards,
> Jonathan.


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joe...@OA...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

Re: [Doxygen-develop] DITA XML Support Status

[<jon...@no...>]

Hi, Joel.

Latest patch and binaries now uploaded to https://projects.developer.nokia.com/doxygen_dita/files/.

> When you say latest, do you mean svn or 1.7.4?

Binaries were built against a svn checkout from today, but the patch should apply cleanly to the last stable doxygen release also.

> Other that the obvious reports of success or details on problems, what type of feedback would you like?

Where you think the format (dtd) could be improved, feature requests, bug reports etc.

> It would be good to get this merged so it because more mainstream.

I have created an "enhancement" on doxygens bugzilla and applied the patch so probably best to continue the conversation over there. The url is: https://bugzilla.gnome.org/show_bug.cgi?id=654087.

> We try not to have quirky code in RTEMS but it wouldn't surprise me if someone else found it quirky.  We use a lot of static inline methods to encapsulate functionality in an OO style.

I am sure the kernel engineers here would take exception to my use of the word "quirky" :), but I'm not as smart as those guys so some of it looks "quirky" to me.

> I am just getting started on this experiment.  Is there a good guide for the process of getting from Doxygen all the way to the Information Centre?

None that I know off. Once you get doxygen outputting the dita xml running the DITA OT with our plug-in should get you most of the way there (DITA OT supports outputting as Eclipse jar files). We need to use 64bit java and give it a LOT of ram to get it to build all of Symbian OS so that might be something to watch out for.

Regards,
Jonathan.

Re: [Doxygen-develop] DITA XML Support Status

[Joel S. <joe...@oa...>]

On 07/06/2011 03:11 AM, jon...@no... wrote:
> Hi, Joel.
>
>> What are the plans for merging this into Doxygen?
> At the moment we continue to maintain it as a separate patch. The latest version (+ windows&  linux binaries) can be downloaded from https://projects.developer.nokia.com/doxygen_dita/files. We plan to upload our latest version in the next few days (a few bug fixes, latest version of doxygen). You can also download the latest DITA OT plug-in from there.
>
Thanks.  I guess I should wait for that patch to try it.  When you
say latest, do you mean svn or 1.7.4?

Other that the obvious reports of success or details on problems,
what type of feedback would you like?

It would be good to get this merged so it because more mainstream.
As you posted recently, QtDoc now produces DITA so it would be
a good time for Doxygen to pick up the capability.
>> You mention this for C++, does it work for C as well?  I am looking at this as a path to getting the RTEMS Doxygen generated documentation into the Eclipse Information Center.
> We haven't tested it extensively on any C code but there is no reason it shouldn't. We use it on Symbian OS (which contains a lot of quirky idioms etc. as you can imagine) so it should suit your needs. Our documentations final destination is normally Eclipse Information Centre aswell.
>
We try not to have quirky code in RTEMS but it wouldn't surprise me
if someone else found it quirky.  We use a lot of static inline methods
to encapsulate functionality in an OO style.

I am just getting started on this experiment.  Is there a good guide
for the process of getting from Doxygen all the way to the
Information Centre?
> If you have any problems/questions regarding it please feel free to get in touch.
>
Thanks.  I really appreciate the offer and will do my best not to
abuse it.
> Regards,
> Jonathan.


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joe...@OA...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

Re: [Doxygen-develop] DITA XML Support Status

[<pau...@no...>]

Hi Joel,

> You mention this for C++, does it work for C as well?

Yes this will work for C, you probably want to set OPTIMIZE_OUTPUT_FOR_C = YES in your config file.

The discrepancy will be is that we treat, for the moment, C input as C++ so that the DITA output will be to the DITA C++ specialisation. There is not yet a DITA specialisation for C. There is some interest in OASIS in creating a Technical Sub-Committee for Programming Languages that could share the burden of creating specialisations but the sub-committee is not yet formed.

If a specialisation for C were to exist then our patch could write to it because it decides output formats dynamically from any inputs that Doxygen can take (see line 25 onwards in xmlditaelementprefix.cpp).

So for the moment, yes, it will take C input but produce DITA to the C++ specialisation. Let us know how you get on!

Best regards,

Paul Ross.

> -----Original Message-----
> From: ext Joel Sherrill [mailto:joe...@oa...]
> Sent: 05 July 2011 23:20
> To: dox...@li...; Harrington Jonathan (Nokia-
> SD/London)
> Subject: [Doxygen-develop] DITA XML Support Status
> 
> > Hi,
> >
> > We are currently working on a DITA XML specialization for the C++
> programming language. As part of the work we have implemented a backend
> for doxygen which produces DITA XML from C++ source code, a documented
> standard and a plug-in for the DITA open toolkit.
> >
> > We have been using the standard, the doxygen backend and DITA open
> toolkit plug-in in production for over a year now to produce the
> Symbian developer library and we feel they are stable enough to start
> donating them to the appropriate upstream projects. We are have started
> discussions with Oasis about approving the C++ standard and our plug-in
> is already available for download on the DITA open toolkit website.
> >
> > I was wondering if anyone else in the doxygen community would be
> interested in this work and if there is any desire to see it integrated
> back up stream? I have attached a patch that adds DITA xml support to
> doxygen. We have tested the patch on windows, Linux and Mac OS X and
> would be happy to support it (fix any defects raised, implement feature
> requests etc.) for the foreseeable future.
> >
> > Patch can be downloaded
> fromhttp://www.skynet.ie/~jonathan/dita_patch.diff.gz
> <http://www.skynet.ie/%7Ejonathan/dita_patch.diff.gz>
> >
> > Regards,
> > Jonathan.
> 
> What are the plans for merging this into Doxygen?
> 
> You mention this for C++, does it work for C as well?  I am
> looking at this as a path to getting the RTEMS Doxygen
> generated documentation into the Eclipse Information Center.
> 
> Thanks.
> 
> --
> Joel Sherrill, Ph.D.             Director of Research&  Development
> joe...@OA...        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>     Support Available             (256) 722-9985
> 
> 
> 
> -----------------------------------------------------------------------
> -------
> All of the data generated in your IT infrastructure is seriously
> valuable.
> Why? It contains a definitive record of application performance,
> security
> threats, fraudulent activity, and more. Splunk takes this data and
> makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

Re: [Doxygen-develop] DITA XML Support Status

[<jon...@no...>]

Hi, Joel.

> What are the plans for merging this into Doxygen?

At the moment we continue to maintain it as a separate patch. The latest version (+ windows & linux binaries) can be downloaded from https://projects.developer.nokia.com/doxygen_dita/files. We plan to upload our latest version in the next few days (a few bug fixes, latest version of doxygen). You can also download the latest DITA OT plug-in from there.

> You mention this for C++, does it work for C as well?  I am looking at this as a path to getting the RTEMS Doxygen generated documentation into the Eclipse Information Center.

We haven't tested it extensively on any C code but there is no reason it shouldn't. We use it on Symbian OS (which contains a lot of quirky idioms etc. as you can imagine) so it should suit your needs. Our documentations final destination is normally Eclipse Information Centre aswell. 

If you have any problems/questions regarding it please feel free to get in touch.

Regards,
Jonathan.

[Doxygen-develop] DITA XML Support Status

[Joel S. <joe...@oa...>]

> Hi,
>
> We are currently working on a DITA XML specialization for the C++ programming language. As part of the work we have implemented a backend for doxygen which produces DITA XML from C++ source code, a documented standard and a plug-in for the DITA open toolkit.
>
> We have been using the standard, the doxygen backend and DITA open toolkit plug-in in production for over a year now to produce the Symbian developer library and we feel they are stable enough to start donating them to the appropriate upstream projects. We are have started discussions with Oasis about approving the C++ standard and our plug-in is already available for download on the DITA open toolkit website.
>
> I was wondering if anyone else in the doxygen community would be interested in this work and if there is any desire to see it integrated back up stream? I have attached a patch that adds DITA xml support to doxygen. We have tested the patch on windows, Linux and Mac OS X and would be happy to support it (fix any defects raised, implement feature requests etc.) for the foreseeable future.
>
> Patch can be downloaded fromhttp://www.skynet.ie/~jonathan/dita_patch.diff.gz  <http://www.skynet.ie/%7Ejonathan/dita_patch.diff.gz>
>
> Regards,
> Jonathan.

What are the plans for merging this into Doxygen?

You mention this for C++, does it work for C as well?  I am
looking at this as a path to getting the RTEMS Doxygen
generated documentation into the Eclipse Information Center.

Thanks.

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joe...@OA...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985