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

Re: [Doxygen-develop] Build error for Ninja Generator

[masaru t. <m.t...@gm...>]

Hi

I commented to the pull request.


2018年5月3日(木) 1:32 Albert <alb...@gm...>:

> I've just pushed a proposed patch to github (pull request 712,
> https://github.com/doxygen/doxygen/pull/712).
>
> Albert
>
> On Wed, May 2, 2018 at 4:03 PM, Albert <alb...@gm...> wrote:
>
>> Dear Masaru,
>>
>> A bit strange. The construct as used for TEST_FLAGS is the same construct
>> as used for e.g. LEX_FLAGS ad BISON_FLAGS
>> Do you have an idea why it is working for LEX_FLAGS / YACC_FLAGS and not
>> for TEST_FLAGS.
>>
>> I tried to create a Ninja version under Windows but I fail due to the
>> fact that cmake cannot find bison, looks like here are some quotes missing
>> around the YACC_FLAGS. Will have to do some further testing here.
>> When replacing the $(TEST_FLAGS) in the build.ninja by $$(TEST_FLAGS) it
>> looks like to start compiling, also some more tests required.
>>
>> Albert
>>
>>
>>
>> On Wed, May 2, 2018 at 3:09 PM, masaru tsuchiyama <m.t...@gm...>
>> wrote:
>>
>>> Hi
>>>
>>> I found a bug that doxygen can't compile for Ninja generator.
>>> It works for 'Unix Makefiles' generator
>>>
>>> This is the error message.
>>>
>>> ninja: warning: multiple rules generate generated_src/configvalues.h.
>>> builds involving this target will not be correct; continuing anyway [-w
>>> dupbuild=warn]
>>> ninja: error: build.ninja:2384: bad $-escape (literal $ must be written
>>> as $$)
>>>
>>> This is the diff of build.ninja between good revision (
>>> ok_b6f01ff09b17e5c2288f2418ef0a8f074456c357)
>>> and bad revision (c78c338fffbdbb9b2379b1896e647f7cc697da57)
>>>
>>> $ diff build/build.ninja ok_b6f01ff09b17e5c2288f2418ef0a8f074456c357
>>> 2384c2384
>>> <   COMMAND = cd /home/user/gitwork/doxygen/build/testing &&
>>> /usr/bin/python /home/user/gitwork/doxygen/testing/runtests.py
>>> $(TEST_FLAGS) --doxygen /home/user/gitwork/doxygen/build/bin/doxygen
>>> --inputdir /home/user/gitwork/doxygen/testing --outputdir
>>> /home/user/gitwork/doxygen/build/testing
>>> ---
>>> >   COMMAND = cd /home/user/gitwork/doxygen/build/testing &&
>>> /usr/bin/python /home/user/gitwork/doxygen/testing/runtests.py --all
>>> --doxygen /home/user/gitwork/doxygen/build/bin/doxygen --inputdir
>>> /home/user/gitwork/doxygen/testing --outputdir
>>> /home/user/gitwork/doxygen/build/testing
>>>
>>> By tweaking  $(TEST_FLAGS) to  --all, the build succeeded.
>>>
>>> This is a script to reproduce.
>>>
>>> -------------------------------------------------------------------------------
>>> #!/bin/sh
>>>
>>> if [ -e build ]; then
>>>   rm -rf build
>>> fi
>>> mkdir build
>>> cd build
>>>
>>> cmake -G Ninja -D CMAKE_BUILD_TYPE=Release ..
>>> cmake --build . -- -j 3 -v || echo error && cd .. && exit 1
>>>
>>> cd ..
>>>
>>> -------------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Doxygen-develop mailing list
>>> Dox...@li...
>>> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>>>
>>>
>>
>

Re: [Doxygen-develop] Build error for Ninja Generator

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

I've just pushed a proposed patch to github (pull request 712,
https://github.com/doxygen/doxygen/pull/712).

Albert

On Wed, May 2, 2018 at 4:03 PM, Albert <alb...@gm...> wrote:

> Dear Masaru,
>
> A bit strange. The construct as used for TEST_FLAGS is the same construct
> as used for e.g. LEX_FLAGS ad BISON_FLAGS
> Do you have an idea why it is working for LEX_FLAGS / YACC_FLAGS and not
> for TEST_FLAGS.
>
> I tried to create a Ninja version under Windows but I fail due to the fact
> that cmake cannot find bison, looks like here are some quotes missing
> around the YACC_FLAGS. Will have to do some further testing here.
> When replacing the $(TEST_FLAGS) in the build.ninja by $$(TEST_FLAGS) it
> looks like to start compiling, also some more tests required.
>
> Albert
>
>
>
> On Wed, May 2, 2018 at 3:09 PM, masaru tsuchiyama <m.t...@gm...>
> wrote:
>
>> Hi
>>
>> I found a bug that doxygen can't compile for Ninja generator.
>> It works for 'Unix Makefiles' generator
>>
>> This is the error message.
>>
>> ninja: warning: multiple rules generate generated_src/configvalues.h.
>> builds involving this target will not be correct; continuing anyway [-w
>> dupbuild=warn]
>> ninja: error: build.ninja:2384: bad $-escape (literal $ must be written
>> as $$)
>>
>> This is the diff of build.ninja between good revision (
>> ok_b6f01ff09b17e5c2288f2418ef0a8f074456c357)
>> and bad revision (c78c338fffbdbb9b2379b1896e647f7cc697da57)
>>
>> $ diff build/build.ninja ok_b6f01ff09b17e5c2288f2418ef0a8f074456c357
>> 2384c2384
>> <   COMMAND = cd /home/user/gitwork/doxygen/build/testing &&
>> /usr/bin/python /home/user/gitwork/doxygen/testing/runtests.py
>> $(TEST_FLAGS) --doxygen /home/user/gitwork/doxygen/build/bin/doxygen
>> --inputdir /home/user/gitwork/doxygen/testing --outputdir
>> /home/user/gitwork/doxygen/build/testing
>> ---
>> >   COMMAND = cd /home/user/gitwork/doxygen/build/testing &&
>> /usr/bin/python /home/user/gitwork/doxygen/testing/runtests.py --all
>> --doxygen /home/user/gitwork/doxygen/build/bin/doxygen --inputdir
>> /home/user/gitwork/doxygen/testing --outputdir
>> /home/user/gitwork/doxygen/build/testing
>>
>> By tweaking  $(TEST_FLAGS) to  --all, the build succeeded.
>>
>> This is a script to reproduce.
>> ------------------------------------------------------------
>> -------------------
>> #!/bin/sh
>>
>> if [ -e build ]; then
>>   rm -rf build
>> fi
>> mkdir build
>> cd build
>>
>> cmake -G Ninja -D CMAKE_BUILD_TYPE=Release ..
>> cmake --build . -- -j 3 -v || echo error && cd .. && exit 1
>>
>> cd ..
>> ------------------------------------------------------------
>> -------------------
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Doxygen-develop mailing list
>> Dox...@li...
>> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>>
>>
>

[Doxygen-develop] looking for users of sqlite3 output extension

[Travis E. <tra...@gm...>]

Hi all,

Looking for anyone who uses the extension to get a sense of how you consume
the database and what kinds of queries you run.

I'm entering the home stretch of a project to fill out and improve the
experimental sqlite3 output extension, so I'm evaluating what I can do to
mitigate disruptions.

Thanks,
Travis

Re: [Doxygen-develop] Build error for Ninja Generator

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

Dear Masaru,

A bit strange. The construct as used for TEST_FLAGS is the same construct
as used for e.g. LEX_FLAGS ad BISON_FLAGS
Do you have an idea why it is working for LEX_FLAGS / YACC_FLAGS and not
for TEST_FLAGS.

I tried to create a Ninja version under Windows but I fail due to the fact
that cmake cannot find bison, looks like here are some quotes missing
around the YACC_FLAGS. Will have to do some further testing here.
When replacing the $(TEST_FLAGS) in the build.ninja by $$(TEST_FLAGS) it
looks like to start compiling, also some more tests required.

Albert



On Wed, May 2, 2018 at 3:09 PM, masaru tsuchiyama <m.t...@gm...>
wrote:

> Hi
>
> I found a bug that doxygen can't compile for Ninja generator.
> It works for 'Unix Makefiles' generator
>
> This is the error message.
>
> ninja: warning: multiple rules generate generated_src/configvalues.h.
> builds involving this target will not be correct; continuing anyway [-w
> dupbuild=warn]
> ninja: error: build.ninja:2384: bad $-escape (literal $ must be written as
> $$)
>
> This is the diff of build.ninja between good revision ( ok_
> b6f01ff09b17e5c2288f2418ef0a8f074456c357)
> and bad revision (c78c338fffbdbb9b2379b1896e647f7cc697da57)
>
> $ diff build/build.ninja ok_b6f01ff09b17e5c2288f2418ef0a8f074456c357
> 2384c2384
> <   COMMAND = cd /home/user/gitwork/doxygen/build/testing &&
> /usr/bin/python /home/user/gitwork/doxygen/testing/runtests.py
> $(TEST_FLAGS) --doxygen /home/user/gitwork/doxygen/build/bin/doxygen
> --inputdir /home/user/gitwork/doxygen/testing --outputdir
> /home/user/gitwork/doxygen/build/testing
> ---
> >   COMMAND = cd /home/user/gitwork/doxygen/build/testing &&
> /usr/bin/python /home/user/gitwork/doxygen/testing/runtests.py --all
> --doxygen /home/user/gitwork/doxygen/build/bin/doxygen --inputdir
> /home/user/gitwork/doxygen/testing --outputdir /home/user/gitwork/doxygen/
> build/testing
>
> By tweaking  $(TEST_FLAGS) to  --all, the build succeeded.
>
> This is a script to reproduce.
> ------------------------------------------------------------
> -------------------
> #!/bin/sh
>
> if [ -e build ]; then
>   rm -rf build
> fi
> mkdir build
> cd build
>
> cmake -G Ninja -D CMAKE_BUILD_TYPE=Release ..
> cmake --build . -- -j 3 -v || echo error && cd .. && exit 1
>
> cd ..
> ------------------------------------------------------------
> -------------------
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>
>

[Doxygen-develop] Build error for Ninja Generator

[masaru t. <m.t...@gm...>]

Hi

I found a bug that doxygen can't compile for Ninja generator.
It works for 'Unix Makefiles' generator

This is the error message.

ninja: warning: multiple rules generate generated_src/configvalues.h.
builds involving this target will not be correct; continuing anyway [-w
dupbuild=warn]
ninja: error: build.ninja:2384: bad $-escape (literal $ must be written as
$$)

This is the diff of build.ninja between good revision (
ok_b6f01ff09b17e5c2288f2418ef0a8f074456c357)
and bad revision (c78c338fffbdbb9b2379b1896e647f7cc697da57)

$ diff build/build.ninja ok_b6f01ff09b17e5c2288f2418ef0a8f074456c357
2384c2384
<   COMMAND = cd /home/user/gitwork/doxygen/build/testing &&
/usr/bin/python /home/user/gitwork/doxygen/testing/runtests.py
$(TEST_FLAGS) --doxygen /home/user/gitwork/doxygen/build/bin/doxygen
--inputdir /home/user/gitwork/doxygen/testing --outputdir
/home/user/gitwork/doxygen/build/testing
---
>   COMMAND = cd /home/user/gitwork/doxygen/build/testing &&
/usr/bin/python /home/user/gitwork/doxygen/testing/runtests.py --all
--doxygen /home/user/gitwork/doxygen/build/bin/doxygen --inputdir
/home/user/gitwork/doxygen/testing --outputdir
/home/user/gitwork/doxygen/build/testing

By tweaking  $(TEST_FLAGS) to  --all, the build succeeded.

This is a script to reproduce.
-------------------------------------------------------------------------------
#!/bin/sh

if [ -e build ]; then
  rm -rf build
fi
mkdir build
cd build

cmake -G Ninja -D CMAKE_BUILD_TYPE=Release ..
cmake --build . -- -j 3 -v || echo error && cd .. && exit 1

cd ..
-------------------------------------------------------------------------------

Re: [Doxygen-develop] @snippetdoc and <table>

[dmA <do...@ma...>]

I made a testproject and thereby I discovered the reason of the problem: 
I'm using the alias "@tc" for "<td class="fieldtype" align="center">" in 
the modul. If I replace the alias with the complete command it works. I 
saw that constraint not in the documentation, so it should be added, but 
the topic can be closed.


Am 21.03.2018 um 12:47 schrieb Albert:
> Please post an example i.e.  a, small, self contained example 
> (source+config file in a tar or zip) that allows us to reproduce the 
> problem.
>
> On Sun, Mar 18, 2018 at 5:08 PM, dmA <do...@ma... 
> <mailto:do...@ma...>> wrote:
>
>     I wrote short descriptions for each modul, inside the moduls, and
>     want to
>     collect this description on one overview-page. This is not a
>     problem, except
>     I use "
>     " in the description. In this case the table is lost on the
>     overview-page,
>     the surrounding text is there.
>
>     I use doxygen V1.8.14 on a w7 and I thing this is a bug?
>
>
>
>     --
>     Sent from:
>     http://doxygen.10944.n7.nabble.com/Doxygen-Development-f5093.html
>     <http://doxygen.10944.n7.nabble.com/Doxygen-Development-f5093.html>
>
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     _______________________________________________
>     Doxygen-develop mailing list
>     Dox...@li...
>     <mailto:Dox...@li...>
>     https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>     <https://lists.sourceforge.net/lists/listinfo/doxygen-develop>
>
>

Re: [Doxygen-develop] @snippetdoc and <table>

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

Please post an example i.e.  a, small, self contained example
(source+config file in a tar or zip) that allows us to reproduce the
problem.

On Sun, Mar 18, 2018 at 5:08 PM, dmA <do...@ma...> wrote:

> I wrote short descriptions for each modul, inside the moduls, and want to
> collect this description on one overview-page. This is not a problem,
> except
> I use "
> " in the description. In this case the table is lost on the overview-page,
> the surrounding text is there.
>
> I use doxygen V1.8.14 on a w7 and I thing this is a bug?
>
>
>
> --
> Sent from: http://doxygen.10944.n7.nabble.com/Doxygen-
> Development-f5093.html
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>

[Doxygen-develop] @snippetdoc and <table>

[dmA <do...@ma...>]

I wrote short descriptions for each modul, inside the moduls, and want to
collect this description on one overview-page. This is not a problem, except
I use "
" in the description. In this case the table is lost on the overview-page,
the surrounding text is there.

I use doxygen V1.8.14 on a w7 and I thing this is a bug?



--
Sent from: http://doxygen.10944.n7.nabble.com/Doxygen-Development-f5093.html

Re: [Doxygen-develop] htmlinclude in paragraph

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

Martin,

I think the best way to solve this problem by means of using ^^ instead of
the \n in ALIAS command.
Furthermore I think that it is wise to have befoe the \par also a ^^.
The documentation of doxygen is not completely up to date regarding this
issue though.

Albert

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Feb 5, 2018 at 9:30 AM, <Mar...@in...> wrote:

> Hi @all
>
>
>
> I have evaluated Doxygen 1.8.14 for using. I noticed a behavior with
> including NSDs (Moritz). Following you can see the include command of
> doxygen.cfg:
>
>
>
> ALIASES = “extended_diagrams{1}=\if DOXYGEN_EXTENDED_DIAGRAMS_NSD  \par
> Nassi Shneiderman Diagram \n \htmlinclude \1.html \endif
>
>
>
> Warning: Illegal command n as part of a title section
>
> Warning: Illegal command htmlinclude as part of a title section
>
>
>
>
>
> I have solved this issue with following:
>
>
>
> ALIASES = “extended_diagrams{1}=\if DOXYGEN_EXTENDED_DIAGRAMS_NSD  <br>
> \htmlinclude \1.html \endif
>
>
>
> With this the NSDs are included correctly and no warnings or errors are
> reported.
>
> But in general can somebody tell me a solution for including html within
> the paragraph section?
>
> Or should I report a Bug?
>
>
>
> BR
>
>
>
> Martin
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>
>

[Doxygen-develop] htmlinclude in paragraph

[<Mar...@in...>]

Hi @all



I have evaluated Doxygen 1.8.14 for using. I noticed a behavior with including NSDs (Moritz). Following you can see the include command of doxygen.cfg:



ALIASES = "extended_diagrams{1}=\if DOXYGEN_EXTENDED_DIAGRAMS_NSD  \par Nassi Shneiderman Diagram \n \htmlinclude \1.html \endif



Warning: Illegal command n as part of a title section

Warning: Illegal command htmlinclude as part of a title section





I have solved this issue with following:



ALIASES = "extended_diagrams{1}=\if DOXYGEN_EXTENDED_DIAGRAMS_NSD  <br> \htmlinclude \1.html \endif



With this the NSDs are included correctly and no warnings or errors are reported.

But in general can somebody tell me a solution for including html within the paragraph section?

Or should I report a Bug?



BR



Martin

Re: [Doxygen-develop] [PATCH] Support for C++ comments next to arguments of macro function

[Christian S. <sch...@cr...>]

On Sonntag, 10. Dezember 2017 20:25:16 CET Albert wrote:
> Dear Christian,
> 
> Not sure if this is wanted., especially when the second part of the comment
> spans multiple lines. In this case we see now multiple lines in the comment
> although the intention, by the documentation writer, was just one block but
> this could lead to an incredible long line in the original source.

Not sure if we have a misapprehension here: the output I showed to you with 
that many spaces is just temporary data right at the point where the macro got 
expanded internally by the lexer. Those superfluous spaces will be filtered out 
immediately right after that point and will end up nowhere; so you will 
neither find those spaces anywere in the generated documentation, nor in the 
referenced sources.

The part where you criticism is valid though, is that this patch does not 
merge the individual comment lines from your example, and that you might thus 
end up with more line feeds in the generated member explanation text than 
originally desired by the author. So this:

DECLARE_ENUM(Foo_t,
    foo1 ///< 1st comment.
         ///< 2nd comment.
         ///< 3rd comment.
);

becomes this:

"1st comment.\n2nd comment.\n3rd comment."

instead of:

"1st comment. 2nd comment. 3rd comment."

But to be really honest with you: this is really a minor issue IMO that can 
still be addressed, compared to the current situation. Just to make this 
clear: right now with latest git master head, C++ comments in the latter 
example end up like this after the preprocessor stage of Doxygen:

----------------------------------------------
///< 1st comment.
///< 2nd comment.
///< 3rd comment.

enum Foo_t { foo1 }
----------------------------------------------

And accordingly you currently end up with no documentation at all for any of 
those enum members, and additionall you might even end up with those orphaned 
text blocks to be sticked to wrong (preceding the enum) code blocks instead.

Best regards,
Christian Schoenebeck

Re: [Doxygen-develop] [PATCH] Support for C++ comments next to arguments of macro function

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

Dear Christian,

Not sure if this is wanted., especially when the second part of the comment
spans multiple lines. In this case we see now multiple lines in the comment
although the intention, by the documentation writer, was just one block but
this could lead to an incredible long line in the original source.

Albert

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Dec 10, 2017 at 8:14 PM, Christian Schoenebeck via Doxygen-develop <
dox...@li...> wrote:

> On Sonntag, 10. Dezember 2017 19:50:06 CET Albert wrote:
> > Dear Christian,
> >
> > What happens in case of multi-line inline comments?
> > E.g.:
> > DECLARE_ENUM(Foo_t,
> >      foo1 = 0x000000001, ///< First comment.
> >                                     ///< continuation of first comment
> >      foo2 = 22, ///< Second comment.
> >                     ///< continuation of second comment
> >      foo3
> >  );
>
> Internally that example macro would first be expanded by the lexer like
> this:
>
> enum Foo_t {     foo1 = 0x000000001, /**< First comment. */
>                     /**< continuation of first comment */     foo2 = 22,
> /**< Second comment. */                    /**< continuation of second
> comment */     foo3 };
>
> Everything in one line at this point.
>
> And in the final (i.e. html) document the enum member "foo1" for example
> would then end up with the following explanation text (tested):
>
> ---------------------------
> First comment
> [NEW-LINE]
> continuation of first comment
> ---------------------------
>
> Best regards,
> Christian Schoenebeck
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>

Re: [Doxygen-develop] [PATCH] Support for C++ comments next to arguments of macro function

[Christian S. <sch...@cr...>]

On Sonntag, 10. Dezember 2017 19:50:06 CET Albert wrote:
> Dear Christian,
> 
> What happens in case of multi-line inline comments?
> E.g.:
> DECLARE_ENUM(Foo_t,
>      foo1 = 0x000000001, ///< First comment.
>                                     ///< continuation of first comment
>      foo2 = 22, ///< Second comment.
>                     ///< continuation of second comment
>      foo3
>  );

Internally that example macro would first be expanded by the lexer like this:

enum Foo_t {     foo1 = 0x000000001, /**< First comment. */                                    /**< continuation of first comment */     foo2 = 22, /**< Second comment. */                    /**< continuation of second comment */     foo3 };

Everything in one line at this point.

And in the final (i.e. html) document the enum member "foo1" for example would then end up with the following explanation text (tested):

---------------------------
First comment
[NEW-LINE]
continuation of first comment
---------------------------

Best regards,
Christian Schoenebeck

Re: [Doxygen-develop] [PATCH] Support for C++ comments next to arguments of macro function

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

Dear Christian,

What happens in case of multi-line inline comments?
E.g.:
DECLARE_ENUM(Foo_t,
     foo1 = 0x000000001, ///< First comment.
                                    ///< continuation of first comment
     foo2 = 22, ///< Second comment.
                    ///< continuation of second comment
     foo3
 );

Best Regards,

Albert

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Dec 10, 2017 at 7:10 PM, Christian Schoenebeck via Doxygen-develop <
dox...@li...> wrote:

> Hi,
>
> please consider the attached patch for git, which allows code input like
> this
> to be processed correctly:
>
>  #ifndef DECLARE_ENUM
>  # define DECLARE_ENUM(type, ...) enum type { __VA_ARGS__ }
>  #endif
>
>  DECLARE_ENUM(Foo_t,
>      foo1 = 0x000000001, ///< First comment.
>      foo2 = 22, ///< Second comment.
>      foo3
>  );
>
> The current general behavior of dropping all new line characters on macro
> expansion is preserved. Accordingly those C++ comments are automatically
> rewritten as inline C comments instead.
>
> Best regards,
> Christian Schoenebeck
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>
>

[Doxygen-develop] [PATCH] Support for C++ comments next to arguments of macro function

[Christian S. <sch...@cr...>]

Hi,

please consider the attached patch for git, which allows code input like this 
to be processed correctly:

 #ifndef DECLARE_ENUM
 # define DECLARE_ENUM(type, ...) enum type { __VA_ARGS__ }
 #endif

 DECLARE_ENUM(Foo_t,
     foo1 = 0x000000001, ///< First comment.
     foo2 = 22, ///< Second comment.
     foo3
 );

The current general behavior of dropping all new line characters on macro 
expansion is preserved. Accordingly those C++ comments are automatically 
rewritten as inline C comments instead.

Best regards,
Christian Schoenebeck

[Doxygen-develop] Bug report: STRIP_FROM_INC_PATH does not work with SHOW_GROUPED_MEMB_INC

[Ambroz B. <am...@gm...>]

Hi,

I'm using Doxygen 1.8.13 with C++ and have enabled both
SHOW_INCLUDE_FILES and SHOW_GROUPED_MEMB_INC, and I have defined
STRIP_FROM_INC_PATH. I see that the latter path prefix is removed from
#include lines in class documentation, but not from #include lines in
detailed documentation of group members.

Best regards,
Ambroz

[Doxygen-develop] Options for scala support

[Ryan B. <rya...@gm...>]

I would like to use doxygen xml output to integrate comment documentation
into other tools. I love that doxygen supports multiple languages but I
would need Scala support in addition to C/C++, Java, C# and Python.

1) Has anyone tried any of the FAQ options
<https://www.stack.nl/%7Edimitri/doxygen/manual/faq.html#faq_pgm_X> to
support Scala? If so, how did it go and what's the best approach?

2) I have considered writing a scaladoc generator that generates doxygen
xml output so I can use the scaladoc -doc-generator option instead doxygen
to parse scala and get the same xml output.

If I did write this scaladoc generator it would be really cool if doxygen
could use it's own xml output format as input as a kind of backward way to
use doxygen on languages like Scala that might have a complex syntax which
makes "tweaking" the doxygen parser to support it a difficult option. Is
using doxygen xml output as doxygen input a possibility?

Best Regards
-- 
Ryan

Re: [Doxygen-develop] Man page titles

[Alastair D'S. <ala...@au...>]

On Mon, 2017-07-24 at 17:01 +1000, Alastair D'Silva wrote:
> Hi folks,
> 
> I'm looking at using Doxygen for generating man pages for an open
> source API project we will be publishing, but have hit a small
> roadblock.
> 
> When generating man pages, the page is titled with the name of the
> source file the definitions were defined in:
> 
> src/afu.c(3)         Library Functions Manual        src/afu.c(3)
> 
> NAME
>        src/afu.c
> 
> SYNOPSIS
>    Functions
> ...
> 
> 
> I would like to override this to provide a more useful description to
> the user, such as "OpenCAPI AFU operations".
> 
> Looking at ManGenerator::endTitleHead, it seems this format is
> hardcoded. I'm happy to post a patch, but would like some advice as
> to
> what command should be used to override the title for the current
> file.
> 
> Cheers,
> 


Scratch that, I was able to name the man page as I wanted by using:/** * @defgroup ocxl_afu OpenCAPI AFU operations * @{ */
-- 
Alastair D'Silva
Open Source Developer
Linux Technology Centre, IBM Australia
mob: 0423 762 819

[Doxygen-develop] Man page titles

[Alastair D'S. <ala...@au...>]

Hi folks,

I'm looking at using Doxygen for generating man pages for an open
source API project we will be publishing, but have hit a small
roadblock.

When generating man pages, the page is titled with the name of the
source file the definitions were defined in:

src/afu.c(3)         Library Functions Manual        src/afu.c(3)

NAME
       src/afu.c

SYNOPSIS
   Functions
...


I would like to override this to provide a more useful description to
the user, such as "OpenCAPI AFU operations".

Looking at ManGenerator::endTitleHead, it seems this format is
hardcoded. I'm happy to post a patch, but would like some advice as to
what command should be used to override the title for the current file.

Cheers,

-- 
Alastair D'Silva
Open Source Developer
Linux Technology Centre, IBM Australia
mob: 0423 762 819

Re: [Doxygen-develop] handling description markup/semantics for SQLite3 "output"?

[Travis E. <tra...@gm...>]

I think maybe we're talking past each other :)

I'm already building out the `generateSqlite3ForPage` work-in-progress stub
you created, and pages currently fit within the existing compounddef SQL
table just as well as they fit within the compounddef XML schema.

My question is whether/how the detaileddescription can be saved in a single
format, so that it's not in at least 3 different formats.

I noticed this problem while building out the "page" type (and used it as a
succinct example of the issue), but it *already* exists for any fields that
can hold arbitrary nested input (such as complex detaileddescriptions on
memberdefs). I've added a 6th file at the end of the gist (
https://gist.github.com/abathur/b3d3d25885303eb216e0ffa2d2604034) containing
the database row for one of our more complex member definitions,
demonstrating this issue. This problem will apply to all additional
compound types as I build them out.

Hope this clarifies,
T

On Mon, Jul 10, 2017 at 11:05 AM, Adrian M Negreanu <gr...@gm...>
wrote:

> Hi,
>  I think, from the gist you posted, that your use case needs to extend the
> current schema so that the elements you see in the xml will also be found
> in sqlite3.
>
> So you'll need a `page` table and add a generateSqlite3ForPage that fills
> in that table.
> Tbis way the semantic you mentioned previously would be provided by the
> new table/attribute.
>
> On Jul 10, 2017 18:57, "Travis Everett" <tra...@gm...>
> wrote:
>
> Hi again Adrian,
>
> I agree with what you've said, but I think that only holds when the
> detaileddescription database field holds a *single* format.
>
> An example of the input/output I'm working with might be more useful than
> my initial description: https://gist.github.com/abathur/b3d3d25885303eb
> 216e0ffa2d2604034
>
> In this example, you can see that the string going into the database
> contains three different formats: an HTML header, plaintext markup, and
> Doxygen commands.
>
> Context: `generateSqlite3ForPage` is one of the parts of sqlite3gen that
> I'm refining as I work on a broader project that generates Doxygen-ready
> source files and markdown pages from a large Sphinx/RST corpus.
>
> Cheers,
> Travis
>
> On Sun, Jul 9, 2017 at 11:48 PM, Adrian M Negreanu <gr...@gm...>
> wrote:
>
>> Hi Travis,
>>
>> The format of the description is dictated by the client's needs. Or in
>> other words, where that description is used.
>>
>> I'm using it from python scripts which makes it easy to parse the current
>> plain text.
>>
>> This brings me to the question : why do you need another format, say (A),
>> when you'll already have to parse the plaintext format to extract the
>> semantic needed by (A) ?
>>
>> One reason for adding (A) is "it's easier for the client to use/parse",
>> which brings me again, to the first part : what client do you have ?
>>
>> Regards
>>
>>
>> On Jul 10, 2017 3:21 AM, "Travis Everett" <tra...@gm...>
>> wrote:
>>
>> All,
>>
>> I'm resuming work on refining the experimental SQLite3 output. I've run
>> into a pretty obvious quandary that I was blissfully ignorant of:
>>
>> Before output-format-specific conversion, it looks like detailed
>> descriptions can include (at least) a mix of HTML and raw text that still
>> contains doxygen commands (I haven't gone fishing, but my guess is that
>> markdown gets translated down to HTML, and output translators are
>> responsible for the rest).
>>
>> When it's being served by an SQL database, it doesn't seem like there's
>> an "obvious" or "expected" format for presentational/semantic markup
>> embedded in the detailed description. I was a bit surprised to find
>> plaintext Doxygen commands present at this stage.
>>
>> I'm curious if anyone has thoughts on how to handle these. The best three
>> paths forward seem to be:
>>
>> - Saving it as XML. I'm not keen on this since it significantly raises
>> the bar on using the sql output, and would require either updating all of
>> the descriptions in place, or parsing them into a more useful form on each
>> use.
>> - Saving an opinionated plaintext translation. This would retain simple
>> usability and avoid the update-all-descriptions or constantly-reparse
>> issues, as long as consumers can live with the format ;)
>> - Some active, user-configurable translation method (probably translate
>> to XML and then call a user-defined translator script as with input
>> filters. *not sure how complex this would be or where to start; may be
>> getting out of my depth.
>>
>> Thanks for any direction,
>> Travis
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Doxygen-develop mailing list
>> Dox...@li...
>> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>>
>>
>>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>
>
>

Re: [Doxygen-develop] handling description markup/semantics for SQLite3 "output"?

[Adrian M N. <gr...@gm...>]

Hi,
 I think, from the gist you posted, that your use case needs to extend the
current schema so that the elements you see in the xml will also be found
in sqlite3.

So you'll need a `page` table and add a generateSqlite3ForPage that fills
in that table.
Tbis way the semantic you mentioned previously would be provided by the new
table/attribute.

On Jul 10, 2017 18:57, "Travis Everett" <tra...@gm...> wrote:

Hi again Adrian,

I agree with what you've said, but I think that only holds when the
detaileddescription database field holds a *single* format.

An example of the input/output I'm working with might be more useful than
my initial description: https://gist.github.com/abathur/b3d3d258853
03eb216e0ffa2d2604034

In this example, you can see that the string going into the database
contains three different formats: an HTML header, plaintext markup, and
Doxygen commands.

Context: `generateSqlite3ForPage` is one of the parts of sqlite3gen that
I'm refining as I work on a broader project that generates Doxygen-ready
source files and markdown pages from a large Sphinx/RST corpus.

Cheers,
Travis

On Sun, Jul 9, 2017 at 11:48 PM, Adrian M Negreanu <gr...@gm...> wrote:

> Hi Travis,
>
> The format of the description is dictated by the client's needs. Or in
> other words, where that description is used.
>
> I'm using it from python scripts which makes it easy to parse the current
> plain text.
>
> This brings me to the question : why do you need another format, say (A),
> when you'll already have to parse the plaintext format to extract the
> semantic needed by (A) ?
>
> One reason for adding (A) is "it's easier for the client to use/parse",
> which brings me again, to the first part : what client do you have ?
>
> Regards
>
>
> On Jul 10, 2017 3:21 AM, "Travis Everett" <tra...@gm...>
> wrote:
>
> All,
>
> I'm resuming work on refining the experimental SQLite3 output. I've run
> into a pretty obvious quandary that I was blissfully ignorant of:
>
> Before output-format-specific conversion, it looks like detailed
> descriptions can include (at least) a mix of HTML and raw text that still
> contains doxygen commands (I haven't gone fishing, but my guess is that
> markdown gets translated down to HTML, and output translators are
> responsible for the rest).
>
> When it's being served by an SQL database, it doesn't seem like there's an
> "obvious" or "expected" format for presentational/semantic markup embedded
> in the detailed description. I was a bit surprised to find plaintext
> Doxygen commands present at this stage.
>
> I'm curious if anyone has thoughts on how to handle these. The best three
> paths forward seem to be:
>
> - Saving it as XML. I'm not keen on this since it significantly raises the
> bar on using the sql output, and would require either updating all of the
> descriptions in place, or parsing them into a more useful form on each use.
> - Saving an opinionated plaintext translation. This would retain simple
> usability and avoid the update-all-descriptions or constantly-reparse
> issues, as long as consumers can live with the format ;)
> - Some active, user-configurable translation method (probably translate to
> XML and then call a user-defined translator script as with input filters.
> *not sure how complex this would be or where to start; may be getting out
> of my depth.
>
> Thanks for any direction,
> Travis
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>
>
>

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Doxygen-develop mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-develop

Re: [Doxygen-develop] handling description markup/semantics for SQLite3 "output"?

[Travis E. <tra...@gm...>]

Hi again Adrian,

I agree with what you've said, but I think that only holds when the
detaileddescription database field holds a *single* format.

An example of the input/output I'm working with might be more useful than
my initial description: https://gist.github.com/abathur/
b3d3d25885303eb216e0ffa2d2604034

In this example, you can see that the string going into the database
contains three different formats: an HTML header, plaintext markup, and
Doxygen commands.

Context: `generateSqlite3ForPage` is one of the parts of sqlite3gen that
I'm refining as I work on a broader project that generates Doxygen-ready
source files and markdown pages from a large Sphinx/RST corpus.

Cheers,
Travis

On Sun, Jul 9, 2017 at 11:48 PM, Adrian M Negreanu <gr...@gm...> wrote:

> Hi Travis,
>
> The format of the description is dictated by the client's needs. Or in
> other words, where that description is used.
>
> I'm using it from python scripts which makes it easy to parse the current
> plain text.
>
> This brings me to the question : why do you need another format, say (A),
> when you'll already have to parse the plaintext format to extract the
> semantic needed by (A) ?
>
> One reason for adding (A) is "it's easier for the client to use/parse",
> which brings me again, to the first part : what client do you have ?
>
> Regards
>
>
> On Jul 10, 2017 3:21 AM, "Travis Everett" <tra...@gm...>
> wrote:
>
> All,
>
> I'm resuming work on refining the experimental SQLite3 output. I've run
> into a pretty obvious quandary that I was blissfully ignorant of:
>
> Before output-format-specific conversion, it looks like detailed
> descriptions can include (at least) a mix of HTML and raw text that still
> contains doxygen commands (I haven't gone fishing, but my guess is that
> markdown gets translated down to HTML, and output translators are
> responsible for the rest).
>
> When it's being served by an SQL database, it doesn't seem like there's an
> "obvious" or "expected" format for presentational/semantic markup embedded
> in the detailed description. I was a bit surprised to find plaintext
> Doxygen commands present at this stage.
>
> I'm curious if anyone has thoughts on how to handle these. The best three
> paths forward seem to be:
>
> - Saving it as XML. I'm not keen on this since it significantly raises the
> bar on using the sql output, and would require either updating all of the
> descriptions in place, or parsing them into a more useful form on each use.
> - Saving an opinionated plaintext translation. This would retain simple
> usability and avoid the update-all-descriptions or constantly-reparse
> issues, as long as consumers can live with the format ;)
> - Some active, user-configurable translation method (probably translate to
> XML and then call a user-defined translator script as with input filters.
> *not sure how complex this would be or where to start; may be getting out
> of my depth.
>
> Thanks for any direction,
> Travis
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>
>
>

Re: [Doxygen-develop] patch submission

[Robert D. <rcd...@gm...>]

Not to speak for Dimitri here, but I think it would probably be
acceptable to create a series of pull requests here:
https://github.com/doxygen/doxygen



On Mon, Oct 3, 2016 at 11:18 AM, johnk <jk...@ar...> wrote:
> I've finally received approval to release some patches I'd written for
> Doxygen.  I'd like to submit them for review and hopefully inclusion in
> future releases.  Though we've discussed it before on the mailing list,
> it's been a long time, so here's what the patches do:
>
> 1) Allow for the generation of class diagrams using PlantUML instead of
> graphviz
>
> 2) Allow for table row and column spans in the markdown syntax
>
> 3) Add some CSS defaults for markdown table formatting
>
>
>
> Dimitri, I'd like to pass the patches on to you.  Do you want them? How
> should I get them to you?
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

Re: [Doxygen-develop] handling description markup/semantics for SQLite3 "output"?

[Adrian M N. <gr...@gm...>]

Hi Travis,

The format of the description is dictated by the client's needs. Or in
other words, where that description is used.

I'm using it from python scripts which makes it easy to parse the current
plain text.

This brings me to the question : why do you need another format, say (A),
when you'll already have to parse the plaintext format to extract the
semantic needed by (A) ?

One reason for adding (A) is "it's easier for the client to use/parse",
which brings me again, to the first part : what client do you have ?

Regards


On Jul 10, 2017 3:21 AM, "Travis Everett" <tra...@gm...>
wrote:

All,

I'm resuming work on refining the experimental SQLite3 output. I've run
into a pretty obvious quandary that I was blissfully ignorant of:

Before output-format-specific conversion, it looks like detailed
descriptions can include (at least) a mix of HTML and raw text that still
contains doxygen commands (I haven't gone fishing, but my guess is that
markdown gets translated down to HTML, and output translators are
responsible for the rest).

When it's being served by an SQL database, it doesn't seem like there's an
"obvious" or "expected" format for presentational/semantic markup embedded
in the detailed description. I was a bit surprised to find plaintext
Doxygen commands present at this stage.

I'm curious if anyone has thoughts on how to handle these. The best three
paths forward seem to be:

- Saving it as XML. I'm not keen on this since it significantly raises the
bar on using the sql output, and would require either updating all of the
descriptions in place, or parsing them into a more useful form on each use.
- Saving an opinionated plaintext translation. This would retain simple
usability and avoid the update-all-descriptions or constantly-reparse
issues, as long as consumers can live with the format ;)
- Some active, user-configurable translation method (probably translate to
XML and then call a user-defined translator script as with input filters.
*not sure how complex this would be or where to start; may be getting out
of my depth.

Thanks for any direction,
Travis

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Doxygen-develop mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] handling description markup/semantics for SQLite3 "output"?

[Travis E. <tra...@gm...>]

All,

I'm resuming work on refining the experimental SQLite3 output. I've run
into a pretty obvious quandary that I was blissfully ignorant of:

Before output-format-specific conversion, it looks like detailed
descriptions can include (at least) a mix of HTML and raw text that still
contains doxygen commands (I haven't gone fishing, but my guess is that
markdown gets translated down to HTML, and output translators are
responsible for the rest).

When it's being served by an SQL database, it doesn't seem like there's an
"obvious" or "expected" format for presentational/semantic markup embedded
in the detailed description. I was a bit surprised to find plaintext
Doxygen commands present at this stage.

I'm curious if anyone has thoughts on how to handle these. The best three
paths forward seem to be:

- Saving it as XML. I'm not keen on this since it significantly raises the
bar on using the sql output, and would require either updating all of the
descriptions in place, or parsing them into a more useful form on each use.
- Saving an opinionated plaintext translation. This would retain simple
usability and avoid the update-all-descriptions or constantly-reparse
issues, as long as consumers can live with the format ;)
- Some active, user-configurable translation method (probably translate to
XML and then call a user-defined translator script as with input filters.
*not sure how complex this would be or where to start; may be getting out
of my depth.

Thanks for any direction,
Travis