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

Re: [Doxygen-develop] Opensearch provider for doxygen docs

[Arnold.Steve <arn...@en...>]

Sounds good to me, but I don't speak for upstream.  What I can do is test a patch in Gentoo, and put it out for other people to play with.  Let me know, or file a Gentoo bug with your patch.

Thanks...

--
Steve

________________________________________
From: Phil Lello [phi...@sq...]
Sent: Monday, June 20, 2011 7:13 PM
To: Dox...@li...
Subject: [Doxygen-develop] Opensearch provider for doxygen docs

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?

Cheers,

Phil Lello


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

The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. This includes the electronic transmission of information and software to foreign countries and to certain foreign nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email to either a foreign national or a foreign destination in violation of such laws.

[Doxygen-develop] Opensearch provider for doxygen docs

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

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?

Cheers,

Phil Lello

[Doxygen-develop] [OT] Cxx DITA adoption

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

Hi,

Slightly OT but I thought it might of interest to people on the list, the guys at Qt have released a version of their documentation tool Qdoc, that supports the DITA C++ standard we developed (using doxygen as the reference implementation). You can see their announcement at http://labs.qt.nokia.com/2011/06/15/the-qt-documentation-has-made-it-into-devnet/.

Our patch for doxygen + binaries can be downloaded from https://projects.developer.nokia.com/doxygen_dita/files.

Regards,
Jon,

Re: [Doxygen-develop] Bug 633448 - support to parse/document tcl

[Rene Z. <r.z...@fr...>]

Hello,

I noticed the new doxygen 1.7.4 release	 and I'm still interested to get tcl 
support into doxygen. Is there anything I can do to make it happen?
Please let me know if ou need additional input.

Regards,
Rene

[Doxygen-develop] doxygen -> SQL

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

Has anyone written a script to convert doxygen xml output to a sql database?

[Doxygen-develop] Doxygen doesn't handle elaborated type specifiers in method parameters correctly

[John S. <jsc...@gm...>]

Doxygen Developers,

I am new to this list but I have been hacking doxygen to get it to work for
me while working on the documentation for the Haiku OS. Congratulations on
creating such a great project with code that is so easy to read and modify.
I have come across an issue with doxygen not handling elaborated type
specifiers correctly. More information on what an elaborated type specifier
is can be found here:

http://msdn.microsoft.com/en-us/library/f432x8c6%28v=vs.80%29.aspx

In short you can include enum, class, struct, or union in front of a method
parameter name. In C++ this is normally optional but if you use the same
type name as the param name then it is required to differentiate them.
Anyway, this is valid C++ and doxygen doesn't parse this correctly. It
instead treats the entire parameter as a type with no name.

Here is an example where this is happening in the documentation for Haiku:

http://api.haiku-os.org/classBTwoDimensionalLayout.html#a8db0a165b3ee1275447af5043d69f00f

Here is the doxygen documentation code for the GetColumnRowConstraints()
function linked above. You can use this code to test the presence of the
bug.

/*!
\fn void BTwoDimensionalLayout::GetColumnRowConstraints(enum
orientation orientation, int32 index, ColumnRowConstraints* constraints)
\brief Fill in the ColumnRowConstraints for a certain column or row in
this BTwoDimensionalLayout.

This method is used to communicate the size constraints and weight for
a given row/column in this BTwoDimensionalLayout.
*/


I have modified doxygen to correct this. It treats the symptoms (fixes the
parsing up after the fact in memberdef.cpp) and not the disease (the parsing
code) but it should be sufficient I think. The patch to correct this issue
on top of  SVN rev 765 is below. If this patch passes your requirements it
would be someone committed it, if not, perhaps I can get some pointers to
make it better.

Index: src/memberdef.cpp
===================================================================
--- src/memberdef.cpp (revision 765)
+++ src/memberdef.cpp (working copy)
@@ -184,6 +184,25 @@
      if (md->isObjCMethod()) { n.prepend("("); n.append(")"); }
      if (a->type!="...")
      {
+        if (a->name.isEmpty())
+        {
+          int sp = a->type.find(' ');
+          int mp = a->type.find(' ', sp+1);
+          if (sp!=-1 && mp!=-1 && mp>sp &&
+              (
+                a->type.left((uint)sp) == "enum" ||
+                a->type.left((uint)sp) == "struct" ||
+                a->type.left((uint)sp) == "union" ||
+                a->type.left((uint)sp) == "class"
+              )
+            )
+            // parameter type has an elaborated type specifier.
+          {
+            a->name = a->type.mid((uint)mp+1);
+            n = a->type = a->type.left((uint)mp);
+            if (md->isObjCMethod()) { n.prepend("("); n.append(")"); }
+          }
+        }
        if (!cName.isEmpty()) n=addTemplateNames(n,cd->name(),cName);

linkifyText(TextGeneratorOLImpl(ol),cd,md->getBodyDef(),md->name(),n);
      }


Thank you,

John Scipione

[Doxygen-develop] doxygen 1.7.4: RPM package spec - version bump

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

Hi

Can the packages/rpm/doxygen.spec be updated?
Version number 1.7.3 just needs to be replaced with 1.7.4 .

Is there some way to do this automatically during release?
I run into same issue with 1.7.2 source bundle.

This seems to be too small bug for Bugzilla.

Thanks 

Jan Ruzicka
Senior Software Engineer
Comtech Mobile Datacom Corporation
20430 Century Blvd, Germantown, MD 20874
Office: 240-686-3300
Fax: 240-686-3301
 
The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

[Doxygen-develop] Crash bug and compile problem

[Philip B. <pb...@sa...>]

Hi,
I have a repeatable crash bug with a problem described as corrupted double-linked list.
I run the 1.7.4 downloaded from doxygen.org on 64-bit linux.

I wanted to build my own version off the trunk to see if it also displays this problem (and in that case enable debug and get a core dump). But alas I cannot build. The compilation fails with a ton of undefined reference to Config::XXX. Anyone else having this problem? Config is not a library class but before I start debugging make I'd like to know if this is a common problem with a common solution?

Doxygen rocks. Just needed to say it.

//Philip

Re: [Doxygen-develop] [Patch] DITA XML support

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

Hi, Morley.


> We're definitely interested in going this route. We currently use Doxygen and
> DITA, and we're looking for a way to generate our C++ reference in DITA. 

As you have probably guessed this is exactly what we do for the Symbian developer library. It is a mixture of authored DITA (~5k topics) and generated DITA from in-source comment (~45k topics), http://bit.ly/i7VRUP. The documentation is built from the exact same source code asset as the phone roms and sdk binaries and we have a linking convention that allows authors to write about APIs using class names, function names etc. with the links being resolved at build time.

> Would you be willing to share a Windows binary file? We'd love to test this out.

Sure, I have uploaded our latest patch + windows and Linux binaries to https://projects.forum.nokia.com/doxygen_dita/files. I have also temporarily uploaded our latest DITA OT plug-in as the one on sourceforge is currently out of date (but I hope to get that updated this week).

If you need any help setting it up or have any non-doxygen related questions please feel free to contact me off list. We would be really interested in another group trying this out and telling us how they get on.

Regards,
Jonathan.

Re: [Doxygen-develop] [Patch] DITA XML support

[Morley <mor...@gm...>]

 <jonathan.harrington <at> nokia.com> writes:





> 
> 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 from http://www.skynet.ie/~jonathan/dita_patch.diff.gz
> 
> Regards,
> Jonathan.
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> 


Hi,

We're definitely interested in going this route. We currently use Doxygen and
DITA, and we're looking for a way to generate our C++ reference in DITA. 

Would you be willing to share a Windows binary file? We'd love to test this out.

Thanks in advance,

Morley

[Doxygen-develop] [Feature Request]: DOT_HIDE_SCOPE_NAMES

[Jason H. <ja...@ja...>]

Hi All,

First thanks for the fantastic tool!

Second, if I may, I would like to request a feature addition of an additional configuration option of DOT_HIDE_SCOPE_NAMES. There is already the configuration option HIDE_SCOPE_NAMES, but this applies everywhere. The class graphs which can get quite complicated are better viewed without the namespaces in our cases, but we would still like to have the namespaces on the rest of the documentation.

I can hack this up by patching the doxygen sources like so:

[Volt:QuickSilver/Development/sandbox/doxygen-svn] ⌘ svn diff
Index: src/dot.cpp
===================================================================
--- src/dot.cpp	(revision 763)
+++ src/dot.cpp	(working copy)
@@ -2067,7 +2067,7 @@
   else // new class
   {
     QCString displayName=className;
-    if (Config_getBool("HIDE_SCOPE_NAMES")) displayName=stripScope(displayName);
+	displayName=stripScope(displayName);
     QCString tmp_url;
     if (cd->isLinkable() && !cd->isHidden()) 
     {
@@ -3026,7 +3026,7 @@
         else
         {
           QCString name;
-          if (Config_getBool("HIDE_SCOPE_NAMES"))
+          if (true)
           {
             name  = rmd->getOuterScope()==m_scope ? 
                     rmd->name() : rmd->qualifiedName();
@@ -3116,7 +3116,7 @@
   uniqueId = md->getReference()+"$"+
              md->getOutputFileBase()+"#"+md->anchor();
   QCString name;
-  if (Config_getBool("HIDE_SCOPE_NAMES"))
+  if (true)
   {
     name = md->name();
   }

But it would of course be nicer to have the option DOT_HIDE_SCOPE_NAMES in doxygen proper.

Thanks!
    Jason

[Doxygen-develop] Enhancement @ingroup for function, variables, etc

[Harpreet S. A. <har...@no...>]

Hi,

Currently, One cannot use multiple ingroup commands for function, variables, etc , this limitation is there to avoid ambiguity in auto-linking of functions to their documentation.

The auto-linking currently refer to the documentation section in the group html page cannot we change this to link to documentation section in file html page so that we can use multiple ingroup command. As sometimes one really need to add the same member in multiple groups.

In documentation of every member, add the groups of which it is a member. (Member of Groups)

Regards,
Harpreet Singh

________________________________

NOTE: This message and its attachments are intended only for the individual or 
entity to which it is addressed and may contain confidential information or 
forward-looking statements regarding product development.  Forward-looking 
statements are subject to change at Atrenta's sole discretion and Atrenta will have 
no liability for the delay or failure to deliver any product or feature mentioned in 
such forward-looking statements.

[Doxygen-develop] Patch: project file

[Ruud A. <ru...@st...>]

Hello,

While pruning my personal git repo of doxygen-1.7.3 I noticed that
layout_default.h isn't generated when it wasn't there to begin with. See the
attached patch to fix this.

-- 
With regards,
Ruud Althuizen
- www.stack.nl
- Unix commissie

Re: [Doxygen-develop] Feature request: group dependency diagram

[Ruud A. <ru...@st...>]

Hello,

Those graphs only show the hierarchy of the groups withing Doxygen. What we
have is a module defined as the group layer1/package2/module4 depending on
layer3/package5/module1 and layer4/package10/module2. (The group names in
this example are only used to represent their location in the layers of the
below layout.)

What this means is that one module can depend on other modules residing in a
completely other layer and/or package. We could create these diagrams
manually per module, but then we have to manually add dependencies of
dependencies.

On Fri 18 Mar 2011 12:13 PM, Dimitri Van Heesch wrote:
> There is already a GROUP_GRAPHS option that shows group relations
> when enabled (in combination with HAVE_DOT=YES). Maybe it already does
> what you want?
> On Mar 18, 2011, at 11:56 , Ruud Althuizen wrote:
> > For a project I'm working on we have our packages and modules sorted into groups:
> > - layer
> >  - package
> >    - module
> > 
> > Most of these modules depend on other packages/modules. We'd like to
> > generate a diagram that shows these depedencies.
> > 
> > We were thinking about defining a new command, '\dependgroup', that gets
> > used the same way as '\ingroup'. So you define a group, where it falls under
> > and on which groups it depends as well.
> > 
> > This way dependency diagrams can be generated, just like with header
> > includes. The reason that the header inclusion diagram isn't working for us
> > is that multiple includes can fit into a single package, we want to group
> > those together.
> > 
> > I was looking at the Doxygen sources to create this functionality myself,
> > but I wasn't sure what I can reuse or what I need to change. If someone can
> > give me directions I can look into it myself.
> > 
> > -- 
> > With regards,
> > Ruud Althuizen
> > - www.stack.nl
> > - Unix commissie
> > ------------------------------------------------------------------------------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit
> > for your organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d_______________________________________________
> > Doxygen-develop mailing list
> > Dox...@li...
> > https://lists.sourceforge.net/lists/listinfo/doxygen-develop
> 

-- 
Met vriendelijke groet,
Ruud Althuizen
- www.stack.nl
- Unix commissie

Re: [Doxygen-develop] Feature request: group dependency diagram

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

Hi Ruud,

There is already a GROUP_GRAPHS option that shows group relations
when enabled (in combination with HAVE_DOT=YES). Maybe it already does
what you want?

Regards,
  Dimitri

On Mar 18, 2011, at 11:56 , Ruud Althuizen wrote:

> Hello,
> 
> For a project I'm working on we have our packages and modules sorted into groups:
> - layer
>  - package
>    - module
> 
> Most of these modules depend on other packages/modules. We'd like to
> generate a diagram that shows these depedencies.
> 
> We were thinking about defining a new command, '\dependgroup', that gets
> used the same way as '\ingroup'. So you define a group, where it falls under
> and on which groups it depends as well.
> 
> This way dependency diagrams can be generated, just like with header
> includes. The reason that the header inclusion diagram isn't working for us
> is that multiple includes can fit into a single package, we want to group
> those together.
> 
> I was looking at the Doxygen sources to create this functionality myself,
> but I wasn't sure what I can reuse or what I need to change. If someone can
> give me directions I can look into it myself.
> 
> -- 
> With regards,
> Ruud Althuizen
> - www.stack.nl
> - Unix commissie
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d_______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] Feature request: group dependency diagram

[Ruud A. <ru...@st...>]

Hello,

For a project I'm working on we have our packages and modules sorted into groups:
- layer
  - package
    - module

Most of these modules depend on other packages/modules. We'd like to
generate a diagram that shows these depedencies.

We were thinking about defining a new command, '\dependgroup', that gets
used the same way as '\ingroup'. So you define a group, where it falls under
and on which groups it depends as well.

This way dependency diagrams can be generated, just like with header
includes. The reason that the header inclusion diagram isn't working for us
is that multiple includes can fit into a single package, we want to group
those together.

I was looking at the Doxygen sources to create this functionality myself,
but I wasn't sure what I can reuse or what I need to change. If someone can
give me directions I can look into it myself.

-- 
With regards,
Ruud Althuizen
- www.stack.nl
- Unix commissie

Re: [Doxygen-develop] Fortran code test suite

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

Hi,

> I once made a couple of simple bash scripts for testing regression, also based
> on doxygen's XML output. I've attached them. The scripts assume a set of test
> files, each starting with a letter t. With the update script you can make a
> reference, and with the check script compare the actual results against
> the reference. Maybe it is of use.
Thats much simpler solution with seemingly the same outcome. I think
I'll play with my for some time.

Oleg

>
> Regards,
>  Dimitri

Re: [Doxygen-develop] Fortran code test suite

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

Hi Oleg,

We have working with Doxygen to generate DITA XML. When we started this we generated C++ reference tests for each tag (and tag combinations) then we could compare Doxygen's DITA XML output with a reference output and test if there were any regressions. This was integrated into our CI server.

We are in the process of preparing a patch for the latest DITA support in Doxygen and updating the DITA specialisation to version 0.7.0 (currently 0.6.0 is available at http://sourceforge.net/projects/dita-ot/files/Plug-in_C%2B%2B%20APIRef/ ).

Our DITA XML test suite is a bit old and needs some work to align it with all the stuff we now support with the current (patched) version of Doxygen. It is, of course, C++ input and DITA XML output but there is no reason why it could not be extended to other input languages and output formats. We found it very useful for detecting errors, especially regressive ones.

We'd be quite happy to share this with the Doxygen community if people think that it would be useful. If so I'll see if we can spend a bit of time getting it into good shape.

Best regards,

Paul.

8<------------------------------->8
Paul Ross
Senior Technology Architect
System Documentation Tools
D RD SD SSS System Doc & Tools GB
Nokia London, UK.

> -----Original Message-----
> From: ext Oleg Batrashev [mailto:og...@gm...]
> Sent: 14 March 2011 18:13
> To: Arnold.Steve
> Cc: dox...@li...
> Subject: Re: [Doxygen-develop] Fortran code test suite
> 
> Hi,
> 
> > I found there is an xml output from Doxygen. Has anyone tried to
> write
> > regression tests based on it, using XPath or any similar technique?
> > It seems to be good tool to verify parsers.
> I've made a try and quite satisfied by now.
> https://github.com/ogbash/doxygen-tests
> 
> Currently there are only 8 tests, where 5 are taken from bug reports.
> Release-1.7.1 gives 7 failures.
> Release-1.7.3-20110217 gives 3 failures out of 8 tests.
> 
> runTest (tests.blocks.interface_abst_f90) ... ok
> runTest (tests.blocks.interface_gen_f90) ... ok
> runTest (tests.blocks.interface_op_f90) ... ok
> runTest (tests.blocks.interface_spec_f90) ... ok
> runTest (tests.syntax.label_endsub) ... ok
> runTest (tests.linecont.parcomment_f) ... FAIL
> runTest (tests.linecont.parcomment_f90) ... FAIL
> runTest (tests.linecont.varcomment_f90) ... FAIL
> 
> 89e2c4 from https://github.com/ogbash/doxygen-f90 gives no errors.
> 
> Writing tests is not trivial but managable after making yourself
> familiar to XPath syntax.
> For example, testing that 'example' subroutine exists in
> 'parcomment.f' file and its 'val' parameter is documented:
> 
>         file = self.getFile("parcomment.f")
>         example = self.getSubprogram(file, "example")
> 
>         desc = self.getParamDescription(example, "val")
>         self.assertEqual(desc.getContent().strip(), "[in] scalar double
> input")
> 
> Testing type of the variable 'as' with XPath:
> 
>         var = self.getModuleVariable(varcomment, "as")
>         self.assertEqual(var.xpathEval("type")[0].getContent().strip(),
>                          "integer, dimension(:,:), pointer")
> 
> 
> Any suggestions, comments, or even new tests are welcome,
> Oleg
> 
> -----------------------------------------------------------------------
> -------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

Re: [Doxygen-develop] [Patch] DITA XML support

[Arnold.Steve <arn...@en...>]

I'd happy to test/package it on Gentoo, but I can't speak for upstream...  But thanks to you and Nokia for the contribution; I wish more organizations had that attitude...

Regards, Steve

Jonathan wrote:
[snip]

> 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 from http://www.skynet.ie/~jonathan/dita_patch.diff.gz


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

The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. This includes the electronic transmission of information and software to foreign countries and to certain foreign nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email to either a foreign national or a foreign destination in violation of such laws.

[Doxygen-develop] [Patch] DITA XML support

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

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 from http://www.skynet.ie/~jonathan/dita_patch.diff.gz

Regards,
Jonathan.

Re: [Doxygen-develop] Fortran code test suite

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

Hi Oleg,

I once made a couple of simple bash scripts for testing regression, also based
on doxygen's XML output. I've attached them. The scripts assume a set of test
files, each starting with a letter t. With the update script you can make a
reference, and with the check script compare the actual results against 
the reference. Maybe it is of use.

Re: [Doxygen-develop] Fortran code test suite

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

Hi,

> I found there is an xml output from Doxygen. Has anyone tried to write
> regression tests based on it, using XPath or any similar technique?
> It seems to be good tool to verify parsers.
I've made a try and quite satisfied by now.
https://github.com/ogbash/doxygen-tests

Currently there are only 8 tests, where 5 are taken from bug reports.
Release-1.7.1 gives 7 failures.
Release-1.7.3-20110217 gives 3 failures out of 8 tests.

runTest (tests.blocks.interface_abst_f90) ... ok
runTest (tests.blocks.interface_gen_f90) ... ok
runTest (tests.blocks.interface_op_f90) ... ok
runTest (tests.blocks.interface_spec_f90) ... ok
runTest (tests.syntax.label_endsub) ... ok
runTest (tests.linecont.parcomment_f) ... FAIL
runTest (tests.linecont.parcomment_f90) ... FAIL
runTest (tests.linecont.varcomment_f90) ... FAIL

89e2c4 from https://github.com/ogbash/doxygen-f90 gives no errors.

Writing tests is not trivial but managable after making yourself
familiar to XPath syntax.
For example, testing that 'example' subroutine exists in
'parcomment.f' file and its 'val' parameter is documented:

        file = self.getFile("parcomment.f")
        example = self.getSubprogram(file, "example")

        desc = self.getParamDescription(example, "val")
        self.assertEqual(desc.getContent().strip(), "[in] scalar double input")

Testing type of the variable 'as' with XPath:

        var = self.getModuleVariable(varcomment, "as")
        self.assertEqual(var.xpathEval("type")[0].getContent().strip(),
                         "integer, dimension(:,:), pointer")


Any suggestions, comments, or even new tests are welcome,
Oleg

Re: [Doxygen-develop] Fwd: Doxygen feature request

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

Hi Sam,

Try using ALIASES in your config file, such as:

ALIASES = "Type=@par Type\n" \
" DefaultRate =@par DefaultRate \n" \
"id=@par Identity\n"

That will put each field in a <simplesect> element in the XML.

Paul Ross.

> -----Original Message-----
> From: ext Sam Price [mailto:the...@gm...]
> Sent: 13 March 2011 03:11
> To: dox...@li...
> Subject: [Doxygen-develop] Fwd: Doxygen feature request
> 
> If I have a structure class as follows
> 
> /*! @ingroup MESSAGES
>  *  @brief brief description here
>  *  @details detailed description here
>  * @Type Periodic
>  * @DefaultRate 1/12
>  * @id 8
>  */
> The xml that gets generated is
> 
> <detaileddescription>
> -
> <para>
> detailed description here
> </para>
> -
> <para>Periodic  1/12  8 </para>
> </detaileddescription>
> 
> I wish it would separate
>  * @Type Periodic
>  * @DefaultRate 1/12
>  * @id 8
> Into individual xml tags
> <id>8</id>
> or maybe
> <arg name="id">8</arg>
> 
> Is there a way to do this?
> If not could someone implement it, or direct me to the files in the
> doxygen code to change/update and Ill make the change?
> --
> Thank you,
> 
> Sam Price
> (707) 742-3726
> 
> -----------------------------------------------------------------------
> -------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] Fwd: Doxygen feature request

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

If I have a structure class as follows

/*! @ingroup MESSAGES
 *  @brief brief description here
 *  @details detailed description here
 * @Type Periodic
 * @DefaultRate 1/12
 * @id 8
 */
The xml that gets generated is

<detaileddescription>
-
<para>
detailed description here
</para>
-
<para>Periodic  1/12  8 </para>
</detaileddescription>

I wish it would separate
 * @Type Periodic
 * @DefaultRate 1/12
 * @id 8
Into individual xml tags
<id>8</id>
or maybe
<arg name="id">8</arg>

Is there a way to do this?
If not could someone implement it, or direct me to the files in the
doxygen code to change/update and Ill make the change?
--
Thank you,

Sam Price
(707) 742-3726

Re: [Doxygen-develop] Fortran code test suite

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

Hi,

>>> I think it would be a good idea to have some sort of test suite to
>>> test if all Fortran constructs and especially the newer ones are
>>> covered by Doxygen.
>> This is a good idea. Especially, if it is possible to match doxygen
>> output against predefined answer, so not only program errors are
>> caught but also failures. I doubt however that it is easy to achieve.

I found there is an xml output from Doxygen. Has anyone tried to write
regression tests based on it, using XPath or any similar technique?
It seems to be good tool to verify parsers.

Oleg