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

[Doxygen-develop] (Re-)Integrating Tcl support into Doxygen questions

[Robert H. <he...@de...>]

I am looking to re-integrating Tcl support into Doxygen.  I have forked the 
github repo of Doxygen and have started working on creating the parsers for 
Tcl, using pyscanner.* and pycode.* as a model and working on the tclscanner.* 
files from doxygen 1.8.13 as a reference.

I have some questions:

doxygen 1.8.* uses a single parser/scanner for each language, but doxygen 
1.9.* uses two: an Outline Parser and a Code Parser.  What is the difference? 
I guess the short answer is the files are parsed in two passes and each of the 
passes of processed differently.  Is there documentation on what each pass 
needs to do?  

-- 
Robert Heller             -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
he...@de...       -- Webhosting Services
    

[Doxygen-develop] Integration of Doxygen into other languages

[chinchi42 <van...@gm...>]

Dear all,

first of all, thank you for all the efforts you put into that project. I
would like to extend Doxygen to other languages like Nodejs or Javascript,
maybe also integrating it into vscode, that you can make comments and it
will generate a documentation in the background and updating it.

I am open for any advices,
with best regards,
Vanessa

Re: [Doxygen-develop] Visual studio macros for OUTPUT_DIRECTORY

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

You wrote:

the archive file name is: doxygenw20140924_1_8_8
>
No this is definitely not the latest version the latest doxygen version is
1.9.1 (see https://www.doxygen.nl/download.html)
Which OS are you using?

I downloaded the latest binary from doxygen site.
>
which site is this (please give the link, especially seen the version there)

It should work with 1.8.8 as well (but still much better to update). Don't
you get a warning / error when you run doxygen? What happens when you run
doxygen outside Visual Studio with the Doxyfile used and the same,
environment, settings?

<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 Wed, Jun 2, 2021 at 9:54 AM Marius Zavincu <mar...@gm...>
wrote:

> I downloaded the latest binary from doxygen site. the archive file name
> is: doxygenw20140924_1_8_8
>
> All macros are defined into Visual studio and paths already exists before
> calling doxygen.exe at post build event.
>
> Do I need another version?
>
> On Wed, Jun 2, 2021 at 10:42 AM Albert <alb...@gm...> wrote:
>
>> As far as I can see this works in doxygen.
>> - which version of doxygen are you using?
>> - the OutputDir has to be set otherwise the used directory will be the
>> root
>> - the output directory is not created recursively so the path up to the
>> last directory has to exists (so in case OutputDir=a/b/c/d/e the path
>> a/b/c/d has to exist, the e will be created). A proposed patch (
>> https://github.com/doxygen/doxygen/pull/8444) exists though.
>> - note the comment in a Doxyfile is not // but # (but in the question
>> probably just to indicate the problem)
>>
>>
>> <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>
>> <#m_899525823274694168_m_-7319742719737917001_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Wed, Jun 2, 2021 at 7:56 AM Marius Zavincu <mar...@gm...>
>> wrote:
>>
>>> Hi,
>>>
>>> I want to be able to use Visual Studio macros to define the
>>> OUTPUT_DIRECTORY inside the configuration file but I noticed that it is not
>>> working. I am able to use these macros for PROJECT_LOGO for example.
>>>
>>> PROJECT_LOGO           = $(ProjectDir)logo/logo.jpg  // this is working
>>> fine
>>> OUTPUT_DIRECTORY   =$(OutputDir)/ // this does not work for me.
>>>
>>> I am calling this config file from command line. I am using the latest
>>> doxy exe file.
>>>
>>> call $(ProjectDir)doxygen.exe $(ProjectDir)doxyfile
>>>
>>> Can someone help me with this? How can I use macros for OUTPUT_DIRECTORY?
>>>
>>> --
>>> Marius Zavincu,
>>> Software Engineer,
>>> Tel: +40745660920
>>>
>>> _______________________________________________
>>> Doxygen-develop mailing list
>>> Dox...@li...
>>> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>>>
>>
>
> --
> Marius Zavincu,
> Software Engineer,
> Tel: +40745660920
>
>

Re: [Doxygen-develop] Visual studio macros for OUTPUT_DIRECTORY

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

As far as I can see this works in doxygen.
- which version of doxygen are you using?
- the OutputDir has to be set otherwise the used directory will be the root
- the output directory is not created recursively so the path up to the
last directory has to exists (so in case OutputDir=a/b/c/d/e the path
a/b/c/d has to exist, the e will be created). A proposed patch (
https://github.com/doxygen/doxygen/pull/8444) exists though.
- note the comment in a Doxyfile is not // but # (but in the question
probably just to indicate the problem)

<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 Wed, Jun 2, 2021 at 7:56 AM Marius Zavincu <mar...@gm...>
wrote:

> Hi,
>
> I want to be able to use Visual Studio macros to define the
> OUTPUT_DIRECTORY inside the configuration file but I noticed that it is not
> working. I am able to use these macros for PROJECT_LOGO for example.
>
> PROJECT_LOGO           = $(ProjectDir)logo/logo.jpg  // this is working
> fine
> OUTPUT_DIRECTORY   =$(OutputDir)/ // this does not work for me.
>
> I am calling this config file from command line. I am using the latest
> doxy exe file.
>
> call $(ProjectDir)doxygen.exe $(ProjectDir)doxyfile
>
> Can someone help me with this? How can I use macros for OUTPUT_DIRECTORY?
>
> --
> Marius Zavincu,
> Software Engineer,
> Tel: +40745660920
>
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>

[Doxygen-develop] Visual studio macros for OUTPUT_DIRECTORY

[Marius Z. <mar...@gm...>]

Hi,

I want to be able to use Visual Studio macros to define the
OUTPUT_DIRECTORY inside the configuration file but I noticed that it is not
working. I am able to use these macros for PROJECT_LOGO for example.

PROJECT_LOGO           = $(ProjectDir)logo/logo.jpg  // this is working fine
OUTPUT_DIRECTORY   =$(OutputDir)/ // this does not work for me.

I am calling this config file from command line. I am using the latest doxy
exe file.

call $(ProjectDir)doxygen.exe $(ProjectDir)doxyfile

Can someone help me with this? How can I use macros for OUTPUT_DIRECTORY?

-- 
Marius Zavincu,
Software Engineer,
Tel: +40745660920

Re: [Doxygen-develop] Generating TOC for .md files

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

Randy,

It is easier to communicate over an issue in the doxygen github issue
tracker, so best is to move n that direction.
Furthermore:
- Can you please attach to such an issue a, small, self contained example
(source+configuration file in a tar or zip) that allows us to reproduce the
problem? Please don't add external links as they might not be persistent.
- Please also specify the full doxygen version used (`doxygen -v`).

<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, Mar 1, 2021 at 5:00 PM Randy Yates <ya...@ie...> wrote:

> if i've specified the "recurse" option, and one of my file types is
> .md (markdown), so that i can get my document files into my generated
> doxy output, how do i group multiple .md files, say, in one specific
> subfolder, under one top-level menu in the doxy output's toc pane (the
> left pane on the main page)?
>
> so e.g., if i have msg/doc1.md and msg/doc2.md, i want there to be one
> Messages entry in the doxygen output with each of the document titles
> as submenus, for example, "How to clean your oven" and "Roast Duck
> Soup Recipe", respectively.
>
> so the doxygen-generated output would have:
>
> Message
>  How to clean your oven
>  Roast Duck Soup Recipe
>
> with the .md contents under each?
>
> i am aware of the "# doctitle" method for naming docs in the toc pane,
> but not how to group them
>
> more generally, where is the format of the doc header comment formats
> inside .md files for doxygen?
>
>  --Randy Yates, DSP/Embedded Firmware Developer
>
>
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>

[Doxygen-develop] Generating TOC for .md files

[Randy Y. <ya...@ie...>]

if i've specified the "recurse" option, and one of my file types is
.md (markdown), so that i can get my document files into my generated
doxy output, how do i group multiple .md files, say, in one specific
subfolder, under one top-level menu in the doxy output's toc pane (the
left pane on the main page)?

so e.g., if i have msg/doc1.md and msg/doc2.md, i want there to be one
Messages entry in the doxygen output with each of the document titles
as submenus, for example, "How to clean your oven" and "Roast Duck
Soup Recipe", respectively.

so the doxygen-generated output would have:

Message
 How to clean your oven
 Roast Duck Soup Recipe

with the .md contents under each?

i am aware of the "# doctitle" method for naming docs in the toc pane,
but not how to group them

more generally, where is the format of the doc header comment formats
inside .md files for doxygen?

 --Randy Yates, DSP/Embedded Firmware Developer

[Doxygen-develop] Add option to layout diagrams vertically

[Pietro M. <pie...@gm...>]

Inheritance diagrams are drawn horizontally, and can extend way beyond the
width of the page, forcing the reader to scroll to the right.

It would be useful to add the option to lay out them vertically in case
they are too wide, e.g. if a base class has more than five derived classes,
or if the total width of the derived classes is above a predefined value.

This would provide the classic horizontal layout most of the times, and
just use a vertical one when necessary.

[Doxygen-develop] Anyone working on DocSet .dsidx creation?

[Lorenzo C. <lor...@gm...>]

Hello all,

I was wondering whether anyone is working on issue #6038 (Github issue ref).

I asked the same question on the related comment section of the issue, but I
got no reply.

I already have a prototype patch, which allows the end user to provide
its own preferred database generator, instead of embedding one inside 
doxygen.

Do you know any patch and/or person working on this issue?

Do you believe it would be a nice feature to integrate to project?


Best regards,
Lorenzo Casalino

[Doxygen-develop] Code formatting for contributions

[David H. <dav...@gm...>]

Hello,

are there any guidelines for the code formatting of contributions to
Doxygen? Or even a configuration file for clang-format or Eclipse CDT?

Cheers
David

[Doxygen-develop] Upgrade of custom doxygen

[Matthew W. <mw...@si...>]

Hello,

We use a customized version of doxygen to read C++ source (and 
doxyfiles) and translate it into the equivalent code for perl, python, 
ruby, and tcl.   Why?  Because we use swig to generate modules and 
wrapper libraries extending a suite of database libraries.  Our 
customized version of doxygen filters and modifies the syntax from the 
C++ source substituting the specific scripting language syntax and data 
types.

Our issue is we need to migrate from the doxygen-1.8.7 version to the 
doxygen-1.8.20 version.  A lot has happened between the two and I don't 
have a map to translate from the old methods to the new.  I have 
migrated our custom code from the old configure environment to the cmake 
environment, but I get about a dozen errors for methods that no longer 
exist.  How can I map the old to the new?

Alternatively, can anyone suggest a better way to map the C++ 
documentation without using a customized version of doxygen?

Thanks,

Matthew


-- 
Matthew Wheaton
Silicon Integration Initiative

Senior Programmer
12335 Hymeadow Drive, Suite 450
Austin, TX 78750
mw...@si...
512-745-7810

www.si2.org

[Doxygen-develop] Question

[Jérôme B. <bar...@gm...>]

Hello,

I send directly here in order to ask if a feature is not existing.
I want a way to add some custom tag (as brief for ie).
I want to map features in code. Maybe there is a better tool but for
now i think doxygen is the best option.
for ie i see something like that :
/*
[...]
* features : add user, #354
* features: users validator, #355
[...]
*/

Why i want to do that :
Automaticly close issues, get a better time needed by kind of features
for project planification.
For now it's just an idea i want to test and there is already question :
- How integrate with code library

Feel free to add ideas and potential issues.

[Doxygen-develop] [PATCH doxygen] src: fix bug #7901

[Duncan R. <dun...@op...>]

Modified:

 src/commentscan.l: 0ef84d5 duplicated Detailed Description

 src/groupdef.cpp: 98d3f8e stopped outputting Brief Description

 src/mangen.cpp: 98d3f8e stopped outputting minus sign before B.D.

Signed-off-by: Duncan Roe <dun...@op...>
---
 src/commentscan.l | 1 -
 src/groupdef.cpp  | 1 +
 src/mangen.cpp    | 2 +-
 3 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/commentscan.l b/src/commentscan.l
index 12391cba..bc0529a2 100644
--- a/src/commentscan.l
+++ b/src/commentscan.l
@@ -1906,7 +1906,6 @@ static bool handleDefGroup(yyscan_t yyscanner,const QCString &, const QCStringLi
   struct yyguts_t *yyg = (struct yyguts_t*)yyscanner;
   bool stop=makeStructuralIndicator(yyscanner,Entry::GROUPDOC_SEC);
   yyextra->current->groupDocType = Entry::GROUPDOC_NORMAL;
-  setOutput(yyscanner,OutputBrief);
   BEGIN( GroupDocArg1 );
   return stop;
 }
diff --git a/src/groupdef.cpp b/src/groupdef.cpp
index e4cb180c..0e19c117 100644
--- a/src/groupdef.cpp
+++ b/src/groupdef.cpp
@@ -1207,6 +1207,7 @@ void GroupDefImpl::writeDocumentation(OutputList &ol)
   ol.pushGeneratorState();
   ol.disableAllBut(OutputGenerator::Man);
   ol.endTitleHead(getOutputFileBase(),name());
+  ol.parseText(m_title);
   ol.popGeneratorState();
   ol.endHeaderSection();
   ol.startContents();
diff --git a/src/mangen.cpp b/src/mangen.cpp
index 1faa296f..bab304af 100644
--- a/src/mangen.cpp
+++ b/src/mangen.cpp
@@ -173,7 +173,7 @@ void ManGenerator::endTitleHead(const char *,const char *name)
   t << ".ad l" << endl;
   t << ".nh" << endl;
   t << ".SH NAME" << endl;
-  t << name;
+  t << name << " \\- ";
   m_firstCol=FALSE;
   m_paragraph=TRUE;
   m_inHeader=TRUE;
-- 
2.14.5

Re: [Doxygen-develop] Bug in copydoc for constructor and class documentation

[Max S. <max...@sc...>]

Thank you for the fast answer. I just looked at http://www.doxygen.nl/support.html and missed the git repository.

I submitted an issue at github now: https://github.com/doxygen/doxygen/issues/7247

On Thu, 2019-09-05 at 17:05 +0200, Albert wrote:
- Which version of doxygen are you using? When not the latest version (1.8.16) can you please try this version?
- When persistent: Can you open an issue at: https://github.com/doxygen/doxygen/issues/new with attached a, small, self contained example (source+configuration file in a tar or zip) that allows us to reproduce the problem?  Please don't add external links as they might not be persistent, otherwise please attach the used Doxyfile here.

On Thu, Sep 5, 2019 at 4:59 PM Max Sagebaum <max...@sc...<mailto:max...@sc...>> wrote:
Hello @ all,

I think I found a bug in the Doxygen name resolving scheme together with class documentation and constructor documentation.

I want to copy the documentation of a base class to the inheriting class. The problem is that the default name resolution copies the documentation of the constructor (Case1) and not the class itself. If I try to specify the full name of the class, then in case 3 it still defaults to the constructor documentation. In case 2 it can not find the documentation (In my real world case that worked actually for me, but case 3 is still wrong in the real world case.)

Is this a bug or have I done something wrong.

Best regards

Max

#include <type_traits>

namespace test {

/** ABase Class */
template<typename T>
struct ABase {
  /** ABase Const */
  ABase() {}
};

/** BBase Class */
template<typename T>
struct BBase : public ABase<T> {
  /** BBase Const */
  BBase() {}
};

/* Case1: \copydoc ABase */
/** Case2: \copydoc ::test::ABase */
template<typename T, typename = void>
struct A : public ABase<T> {
  /** A Const */
  A() {}
};

/** Case3: \copydoc ::test::ABase */
template<typename T>
struct A<T, typename std::enable_if<std::is_same<T,double>::value>::type> : public BBase<T> {
  /** A Const */
  A() {}
};

}


--

Dr. Max Sagebaum

Chair for Scientific Computing,
TU Kaiserslautern,
Bldg/Geb 34, Paul-Ehrlich-Strasse,
67663 Kaiserslautern, Germany

Phone: +49 (0)631 205 5638
Fax:   +49 (0)631 205 3056
Email: max...@sc...<mailto:max...@sc...>
URL:   www.scicomp.uni-kl.de<http://www.scicomp.uni-kl.de>






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

--

Dr. Max Sagebaum

Chair for Scientific Computing,
TU Kaiserslautern,
Bldg/Geb 34, Paul-Ehrlich-Strasse,
67663 Kaiserslautern, Germany

Phone: +49 (0)631 205 5638
Fax:   +49 (0)631 205 3056
Email: max...@sc...<mailto:max...@sc...>
URL:   www.scicomp.uni-kl.de

Re: [Doxygen-develop] Bug in copydoc for constructor and class documentation

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

- Which version of doxygen are you using? When not the latest version
(1.8.16) can you please try this version?
- When persistent: Can you open an issue at:
https://github.com/doxygen/doxygen/issues/new with attached a, small, self
contained example (source+configuration file in a tar or zip) that allows
us to reproduce the problem?  Please don't add external links as they might
not be persistent, otherwise please attach the used Doxyfile here.

On Thu, Sep 5, 2019 at 4:59 PM Max Sagebaum <max...@sc...>
wrote:

> Hello @ all,
>
> I think I found a bug in the Doxygen name resolving scheme together with
> class documentation and constructor documentation.
>
> I want to copy the documentation of a base class to the inheriting class.
> The problem is that the default name resolution copies the documentation of
> the constructor (Case1) and not the class itself. If I try to specify the
> full name of the class, then in case 3 it still defaults to the constructor
> documentation. In case 2 it can not find the documentation (In my real
> world case that worked actually for me, but case 3 is still wrong in the
> real world case.)
>
> Is this a bug or have I done something wrong.
>
> Best regards
>
> Max
>
> #include <type_traits>
>
> namespace test {
>
> /** ABase Class */
> template<typename T>
> struct ABase {
>   /** ABase Const */
>   ABase() {}
> };
>
> /** BBase Class */
> template<typename T>
> struct BBase : public ABase<T> {
>   /** BBase Const */
>   BBase() {}
> };
>
> /* Case1: \copydoc ABase */
> /** Case2: \copydoc ::test::ABase */
> template<typename T, typename = void>
> struct A : public ABase<T> {
>   /** A Const */
>   A() {}
> };
>
> /** Case3: \copydoc ::test::ABase */
> template<typename T>
> struct A<T, typename std::enable_if<std::is_same<T,double>::value>::type>
> : public BBase<T> {
>   /** A Const */
>   A() {}
> };
>
> }
>
> --
>
> Dr. Max Sagebaum
>
> Chair for Scientific Computing,
> TU Kaiserslautern,
> Bldg/Geb 34, Paul-Ehrlich-Strasse,
> 67663 Kaiserslautern, Germany
>
> Phone: +49 (0)631 205 5638
> Fax:   +49 (0)631 205 3056
> Email: max...@sc...
> URL:   www.scicomp.uni-kl.de
>
>
>
>
>
>
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>

[Doxygen-develop] Bug in copydoc for constructor and class documentation

[Max S. <max...@sc...>]

Hello @ all,

I think I found a bug in the Doxygen name resolving scheme together with class documentation and constructor documentation.

I want to copy the documentation of a base class to the inheriting class. The problem is that the default name resolution copies the documentation of the constructor (Case1) and not the class itself. If I try to specify the full name of the class, then in case 3 it still defaults to the constructor documentation. In case 2 it can not find the documentation (In my real world case that worked actually for me, but case 3 is still wrong in the real world case.)

Is this a bug or have I done something wrong.

Best regards

Max

#include <type_traits>

namespace test {

/** ABase Class */
template<typename T>
struct ABase {
  /** ABase Const */
  ABase() {}
};

/** BBase Class */
template<typename T>
struct BBase : public ABase<T> {
  /** BBase Const */
  BBase() {}
};

/* Case1: \copydoc ABase */
/** Case2: \copydoc ::test::ABase */
template<typename T, typename = void>
struct A : public ABase<T> {
  /** A Const */
  A() {}
};

/** Case3: \copydoc ::test::ABase */
template<typename T>
struct A<T, typename std::enable_if<std::is_same<T,double>::value>::type> : public BBase<T> {
  /** A Const */
  A() {}
};

}


--

Dr. Max Sagebaum

Chair for Scientific Computing,
TU Kaiserslautern,
Bldg/Geb 34, Paul-Ehrlich-Strasse,
67663 Kaiserslautern, Germany

Phone: +49 (0)631 205 5638
Fax:   +49 (0)631 205 3056
Email: max...@sc...<mailto:max...@sc...>
URL:   www.scicomp.uni-kl.de

[Doxygen-develop] Doxygen new language support.

[Andrew G. <and...@gm...>]

Hello, everyone.

  A colleague and myself are working on Verilog support for Doxygen.  As
some of you know, Verilog is supported in the doxygen-verilog project, but
the Verilog language has expanded considerably since that implementation
was written.

  Our intention is to make IEEE 1800-2012 Verilog and SystemVerilog support
a part of the regular Doxygen project, I'd like to know if there are other
developers adding new languages so that we can compare notes, and use a
consistent approach.

  Is anyone else working on adding new languages?  There's been mention in
the past of a new Doxygen architecture that makes additional languages
easier to support, is that already  implemented in the doxygen code, or are
more changes coming?

  Any advice would be appreciated,
Andrew & David.
Ottawa, Canada.

-- 
===========================================================
“The opposite of love is not hate, it's indifference. The opposite of art
is not ugliness, it's indifference. The opposite of faith is not heresy,
it's indifference. And the opposite of life is not death, it's
indifference.”
― Elie Wiesel <http://www.goodreads.com/author/show/1049.Elie_Wiesel>

[Doxygen-develop] Upgrade jQuery to latest 3.x release

[John W. L. <Joh...@sa...>]

Hello Doxygen developers,

I am not sure what the best way is to contact the Doxygen community, but I am looking for some feedback on how important using the latest jQuery version is to you since the version used now is no longer receiving patches.

https://github.com/doxygen/doxygen/issues/6795

Thanks for any reply,

John Lewis

Re: [Doxygen-develop] Collapsible Code Fragments

[Jacopo P. <jpa...@gm...>]

Many thanks Albert for the quick answer!

I will post it to the issue tracker then.

I still think it would be a great option to have, especially to write
guides through the code and things like that.
Perhaps it could be an opt-in feature controlled by some config, if you
fear it would make things generally too slow.

Jacopo

On Tue, Jan 8, 2019 at 10:52 AM Albert <alb...@gm...> wrote:

> Dear Jacopo,
>
> This is indeed a good place to post it, but I think an even better place
> would be in the doxygen issue tracker (
> https://github.com/doxygen/doxygen/issues/new).
> As is it looks to me like a nice idea, but it will add to the complexity
> of the page handling and to the responsiveness.
> Some collapsible parts can already been seen with e.g. inherited functions
> and class diagrams.
>
> Albert
>
> On Tue, Jan 8, 2019 at 10:42 AM Jacopo Pantaleoni <jpa...@gm...>
> wrote:
>
>> Hello Everyone,
>>
>> I never wrote here so I apologize if this is not the right place for
>> feature requests, but...
>> inspired by the output of literate programming you can find in this book:
>>
>>
>> http://www.pbr-book.org/3ed-2018/Shapes/Basic_Shape_Interface.html#Shape
>>
>> I was wondering that the ability to mark some code blocks collapsible
>> (e.g. inside \code / \endcode or even more importantly in \snippet
>> sections) would make for a _great_ feature.
>>
>> In fact, perhaps one could reuse the block markers already present for
>> \snippet to automatically make sub-blocks collapsible?
>>
>> e.g. if I had:
>>
>> //! [MyBlock]
>> int a;
>> //! [Initialize Vars]
>> a = foo() ;
>> //! [Initialize Vars]
>> ...
>> //! [MyBlock]
>>
>> it would be great if the HTML output for a snippet containing MyBlock
>> contained a collapsible section referring to the block "Initialize Vars".
>>
>> What do you think?
>>
>> Best Regards,
>> -Jacopo
>>
>> _______________________________________________
>> Doxygen-develop mailing list
>> Dox...@li...
>> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>>
>

Re: [Doxygen-develop] Collapsible Code Fragments

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

Dear Jacopo,

This is indeed a good place to post it, but I think an even better place
would be in the doxygen issue tracker (
https://github.com/doxygen/doxygen/issues/new).
As is it looks to me like a nice idea, but it will add to the complexity of
the page handling and to the responsiveness.
Some collapsible parts can already been seen with e.g. inherited functions
and class diagrams.

Albert

On Tue, Jan 8, 2019 at 10:42 AM Jacopo Pantaleoni <jpa...@gm...>
wrote:

> Hello Everyone,
>
> I never wrote here so I apologize if this is not the right place for
> feature requests, but...
> inspired by the output of literate programming you can find in this book:
>
>   http://www.pbr-book.org/3ed-2018/Shapes/Basic_Shape_Interface.html#Shape
>
>
> I was wondering that the ability to mark some code blocks collapsible
> (e.g. inside \code / \endcode or even more importantly in \snippet
> sections) would make for a _great_ feature.
>
> In fact, perhaps one could reuse the block markers already present for
> \snippet to automatically make sub-blocks collapsible?
>
> e.g. if I had:
>
> //! [MyBlock]
> int a;
> //! [Initialize Vars]
> a = foo() ;
> //! [Initialize Vars]
> ...
> //! [MyBlock]
>
> it would be great if the HTML output for a snippet containing MyBlock
> contained a collapsible section referring to the block "Initialize Vars".
>
> What do you think?
>
> Best Regards,
> -Jacopo
>
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>

[Doxygen-develop] Collapsible Code Fragments

[Jacopo P. <jpa...@gm...>]

Hello Everyone,

I never wrote here so I apologize if this is not the right place for
feature requests, but...
inspired by the output of literate programming you can find in this book:

  http://www.pbr-book.org/3ed-2018/Shapes/Basic_Shape_Interface.html#Shape

I was wondering that the ability to mark some code blocks collapsible (e.g.
inside \code / \endcode or even more importantly in \snippet sections)
would make for a _great_ feature.

In fact, perhaps one could reuse the block markers already present for
\snippet to automatically make sub-blocks collapsible?

e.g. if I had:

//! [MyBlock]
int a;
//! [Initialize Vars]
a = foo() ;
//! [Initialize Vars]
...
//! [MyBlock]

it would be great if the HTML output for a snippet containing MyBlock
contained a collapsible section referring to the block "Initialize Vars".

What do you think?

Best Regards,
-Jacopo

Re: [Doxygen-develop] "warning: Internal inconsistency: member XXX does not belong to any container!"

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

Dear Stephan,

Don't know if this is still relevant, but I was not able to reproduce the
problem with 1.8.11 nor with 1.8.14.
When the problem is still persistent please open an issue at
https://github.com/doxygen/doxygen/issues/new and attach a, small, self
contained example (source+config file in a tar or zip) that allows us to
reproduce the problem?

Albert

On Wed, Nov 9, 2016 at 5:48 PM, Stephen Pape <sr...@gm...> wrote:

> Hello,
>
> I'm using Doxygen 1.8.11, which shipped with Ubuntu 16.04. I've also
> tried 1.8.12, compiled from source, which has the same issue.
>
> I have an enum class like this:
>
> namespace foo {
>
> /**
>  *  @brief is a strongly typed enum class representing a supported
> processor type
>  */
> enum class CpuType {
>     /** @brief PowerPC Type 93 */
>     CPU_PPC603 = 93,
>     /** @brief PowerPC Type 112 */
>     CPU_PPC112 = 112,
>     /** @brief The Xtensa processor */
>     CPU_XTENSA = 131,
>     /** @brief Catch-all for unsupported CPUs*/
>     UNKNOWN_CPU_TYPE = -1
> };
>
> }
>
> Doxygen prints out the following:
>
> /home/papes/git/libwdbrpc/include/const/CpuType.hh:24: warning:
> Internal inconsistency: member CPU_PPC603 does not belong to any
> container!
> /home/papes/git/libwdbrpc/include/const/CpuType.hh:24: warning:
> Internal inconsistency: member CPU_PPC603 does not belong to any
> container!
> /home/papes/git/libwdbrpc/include/const/CpuType.hh:26: warning:
> Internal inconsistency: member CPU_PPC112 does not belong to any
> container!
> /home/papes/git/libwdbrpc/include/const/CpuType.hh:26: warning:
> Internal inconsistency: member CPU_PPC112 does not belong to any
> container!
> /home/papes/git/libwdbrpc/include/const/CpuType.hh:28: warning:
> Internal inconsistency: member CPU_XTENSA does not belong to any
> container!
> /home/papes/git/libwdbrpc/include/const/CpuType.hh:28: warning:
> Internal inconsistency: member CPU_XTENSA does not belong to any
> container!
> /home/papes/git/libwdbrpc/include/const/CpuType.hh:31: warning:
> Internal inconsistency: member UNKNOWN_CPU_TYPE does not belong to any
> container!
> /home/papes/git/libwdbrpc/include/const/CpuType.hh:31: warning:
> Internal inconsistency: member UNKNOWN_CPU_TYPE does not belong to any
> container!
>
> This happens with all of my enum classes, and I haven't found a way to
> work around it. I can find the enum in Doxygen if I go through another
> class that uses it, but none of the values are documented. Changing
> them to be regular enums gets rid of the warning, but the values are
> still not documented.
>
> Can anyone offer any insight?
>
> Thanks!
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>

[Doxygen-develop] Build doxmlparser

[Andre S. <and...@va...>]

Hello to all,

I've just joined this list.

I'm starting to work with doxmlparser and noticed that it is not correctly
setup in the CMake files. I'd like to offer myself to adjust that, if you
think it is convenient. I am already able to have doxmlparser.lib and its
example, metrics.exe, compiling on Windows. Need to make it work on other
platforms and, for sure, learn what to do to adhere to the project
standards.

In case you think it is a good idea, I would like very much to get any tip,
advice, etc.

Thank you very much.
André

------------------------------------------------------
Dr. André Sordi
Software Engineer
Professional Scrum Master I
<https://www.scrum.org/Assessments/Certification-Lists?AssessmentName=PSM%20I&l=Sordi%20Braga>
CDV/PL + ASC
E-Mail: and...@va... <vor...@va...>

Valeo Schalter und Sensoren GmbH
Laiernstrasse 12
74321 Bietigheim-Bissingen,
Sitz der Gesellschaft: 74321 Bietigheim-Bissingen
Handelsregister: Amtsgericht Stuttgart - HRB 301795
Vorsitzender des Aufsichtsrates: Knudt-Alexander Ziems
Geschäftsführer: Jens Hälker, Martin Mandry, Stiv Michael Smudja, Pierre-Yves
Veltois

-- 
*This e-mail message is intended for the internal use of the intended 
recipient(s) only.
The information contained herein is 
confidential/privileged. Its disclosure or reproduction is strictly 
prohibited.
If you are not the intended recipient, please inform the sender 
immediately, do not disclose it internally or to third parties and destroy 
it.*

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

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

Dear Masaru,

Thanks for the notification.

Albert

On Thu, May 3, 2018 at 9:53 AM, masaru tsuchiyama <m.t...@gm...>
wrote:

> Sorry, it worked.
>
>
> 2018年5月3日(木) 16:51 Albert <alb...@gm...>:
>
>> Dear Masaru,
>>
>> I saw the comment n github and commented on it. More important for me is
>> does the solution work.
>>
>> 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>
>> <#m_-7810229674902884587_m_-1732287477614699547_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Thu, May 3, 2018 at 12:50 AM, masaru tsuchiyama <m.t...@gm...>
>> wrote:
>>
>>> 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...>]

Dear Masaru,

I saw the comment n github and commented on it. More important for me is
does the solution work.

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 Thu, May 3, 2018 at 12:50 AM, masaru tsuchiyama <m.t...@gm...>
wrote:

> 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
>>>>
>>>>
>>>
>>