doxygen-develop Mailing List for Doxygen
Brought to you by:
dimitri
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
(4) |
Jul
(29) |
Aug
(8) |
Sep
(8) |
Oct
(17) |
Nov
(34) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(20) |
Feb
(14) |
Mar
(11) |
Apr
(9) |
May
(8) |
Jun
(7) |
Jul
(25) |
Aug
(12) |
Sep
(12) |
Oct
(24) |
Nov
(27) |
Dec
(12) |
2003 |
Jan
(12) |
Feb
(14) |
Mar
(15) |
Apr
(11) |
May
(17) |
Jun
(20) |
Jul
(32) |
Aug
(13) |
Sep
(34) |
Oct
(12) |
Nov
(16) |
Dec
(33) |
2004 |
Jan
(20) |
Feb
(6) |
Mar
(20) |
Apr
(15) |
May
(16) |
Jun
(28) |
Jul
(7) |
Aug
(7) |
Sep
(17) |
Oct
(16) |
Nov
(17) |
Dec
(43) |
2005 |
Jan
(15) |
Feb
(5) |
Mar
(14) |
Apr
(4) |
May
(3) |
Jun
(8) |
Jul
(17) |
Aug
(16) |
Sep
(7) |
Oct
(17) |
Nov
(1) |
Dec
(7) |
2006 |
Jan
(7) |
Feb
(6) |
Mar
(10) |
Apr
(6) |
May
(3) |
Jun
(4) |
Jul
(3) |
Aug
(3) |
Sep
(18) |
Oct
(11) |
Nov
(10) |
Dec
(3) |
2007 |
Jan
(12) |
Feb
(12) |
Mar
(23) |
Apr
(5) |
May
(13) |
Jun
(6) |
Jul
(5) |
Aug
(4) |
Sep
(8) |
Oct
(10) |
Nov
(6) |
Dec
(7) |
2008 |
Jan
(7) |
Feb
(13) |
Mar
(35) |
Apr
(14) |
May
(13) |
Jun
(4) |
Jul
(9) |
Aug
(6) |
Sep
(12) |
Oct
(9) |
Nov
(6) |
Dec
(3) |
2009 |
Jan
(2) |
Feb
(2) |
Mar
(2) |
Apr
(15) |
May
(1) |
Jun
(2) |
Jul
(7) |
Aug
(3) |
Sep
(4) |
Oct
(1) |
Nov
(2) |
Dec
(1) |
2010 |
Jan
(4) |
Feb
|
Mar
(5) |
Apr
(1) |
May
(5) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(11) |
Oct
(2) |
Nov
(1) |
Dec
(5) |
2011 |
Jan
(12) |
Feb
(3) |
Mar
(28) |
Apr
(4) |
May
(3) |
Jun
(4) |
Jul
(15) |
Aug
(12) |
Sep
(2) |
Oct
(3) |
Nov
(6) |
Dec
(3) |
2012 |
Jan
(1) |
Feb
(4) |
Mar
(9) |
Apr
(5) |
May
(6) |
Jun
(6) |
Jul
(3) |
Aug
(3) |
Sep
(4) |
Oct
(2) |
Nov
(9) |
Dec
(7) |
2013 |
Jan
(8) |
Feb
(14) |
Mar
(15) |
Apr
(21) |
May
(29) |
Jun
(34) |
Jul
(3) |
Aug
(7) |
Sep
(13) |
Oct
(1) |
Nov
(3) |
Dec
(5) |
2014 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(2) |
Jun
(4) |
Jul
(2) |
Aug
(2) |
Sep
(4) |
Oct
(4) |
Nov
(4) |
Dec
(2) |
2015 |
Jan
(7) |
Feb
(4) |
Mar
(3) |
Apr
(15) |
May
(4) |
Jun
(9) |
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
(3) |
Dec
(7) |
2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(5) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(5) |
2018 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
|
May
(7) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
2021 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Robert H. <he...@de...> - 2022-11-20 20:12:56
|
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 |
From: chinchi42 <van...@gm...> - 2022-08-08 11:39:10
|
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 |
From: Albert <alb...@gm...> - 2021-06-02 08:05:17
|
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 > > |
From: Albert <alb...@gm...> - 2021-06-02 07:43:06
|
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 > |
From: Marius Z. <mar...@gm...> - 2021-06-02 05:56:26
|
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 |
From: Albert <alb...@gm...> - 2021-03-01 16:40:36
|
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 > |
From: Randy Y. <ya...@ie...> - 2021-03-01 16:00:05
|
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 |
From: Pietro M. <pie...@gm...> - 2021-01-27 17:56:43
|
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. |
From: Lorenzo C. <lor...@gm...> - 2021-01-13 09:55:27
|
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 |
From: David H. <dav...@gm...> - 2020-12-24 12:57:11
|
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 |
From: Matthew W. <mw...@si...> - 2020-11-06 01:26:24
|
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 |
From: Jérôme B. <bar...@gm...> - 2020-10-19 17:12:38
|
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. |
From: Duncan R. <dun...@op...> - 2020-07-16 04:17:03
|
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 |
From: Max S. <max...@sc...> - 2019-09-06 06:54:03
|
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 |
From: Albert <alb...@gm...> - 2019-09-05 15:05:39
|
- 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 > |
From: Max S. <max...@sc...> - 2019-09-05 14:59:09
|
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 |
From: Andrew G. <and...@gm...> - 2019-03-27 11:24:05
|
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> |
From: John W. L. <Joh...@sa...> - 2019-01-26 00:41:43
|
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 |
From: Jacopo P. <jpa...@gm...> - 2019-01-08 11:06:02
|
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 >> > |
From: Albert <alb...@gm...> - 2019-01-08 09:53:00
|
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 > |
From: Jacopo P. <jpa...@gm...> - 2019-01-08 09:41:35
|
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 |
From: Albert <alb...@gm...> - 2018-08-08 12:07:48
|
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 > |
From: Andre S. <and...@va...> - 2018-06-20 14:00:54
|
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.* |
From: Albert <alb...@gm...> - 2018-05-03 07:55:38
|
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 >>>>>> >>>>>> >>>>> >>>> >> |
From: Albert <alb...@gm...> - 2018-05-03 07:51:56
|
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 >>>> >>>> >>> >> |