doxygen-develop Mailing List for Doxygen (Page 3)
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: Bonn, J. <jb...@us...> - 2017-05-22 16:30:00
|
In cmake/FindIconv.cmake the fix is: change iconv(iconv_t(-1), 0, 0, 0, 0); to iconv((iconv_t)-1, 0, 0, 0, 0); in 3 places ++++++++++++++++++++++++++++ bash-4.3$ cat test.c #include <iconv.h> int main() { iconv(iconv_t(-1), 0, 0, 0, 0); } bash-4.3$ gcc test.c In file included from test.c:1:0: test.c: In function ‘main’: test.c:3:15: error: expected expression before ‘libiconv_t’ iconv(iconv_t(-1), 0, 0, 0, 0); ^ In file included from test.c:1:0: test.c:3:9: error: too few arguments to function ‘libiconv’ iconv(iconv_t(-1), 0, 0, 0, 0); ^ /usr/local/include/iconv.h:82:15: note: declared here extern size_t iconv (iconv_t cd, char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft); ^ bash-4.3$ gcc --version gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1) Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. bash-4.3$ vi test.c bash-4.3$ cat test.c #include <iconv.h> int main() { iconv((iconv_t)-1, 0, 0, 0, 0); } bash-4.3$ gcc test.c /tmp/ccsr6URT.o: In function `main': test.c:(.text+0x21): undefined reference to `libiconv' collect2: error: ld returned 1 exit status bash-4.3$ |
From: Juraj Z. <jur...@gm...> - 2016-12-23 16:16:16
|
Hello, I've recently opened a stackoverflow question regarding strange issue. http://stackoverflow.com/questions/41229596/doxygen- brief-description-from-within-macro-expansion Someone in the comments pointed out a workaround for the problem. However I'm still concerned whether it's not a bug. I don't really know how this mailing list works, but I'd like to give this issue a little more attention. In case you consider not being a bug, I'll close the stackoverflow question and post the workaround suggested in comments as an answer. Best regards Juraj Zikmund |
From: Stephen P. <sr...@gm...> - 2016-11-09 16:48:46
|
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! |
From: johnk <jk...@ar...> - 2016-10-03 16:52:50
|
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? |
From: Dominic A. <dom...@gm...> - 2016-08-31 17:06:19
|
I have submitted a report (based on what I get using python). My doxygen version is 1.8.11. BTW - doxygen is awesome, and you guys are awesome for maintaining it. On 31 August 2016 at 12:56, Albert <alb...@gm...> wrote: > Dominic, > > I can reproduce it with python code, the small test I ran before used C > code and didn't show the line numbers, so we have a second problem here. > We have to dive into these problems, please submit bug reports for it. > > Note: you use as snippet identification transducer setup which is at the > moment fully correct, but please use transducer_setup as the definition > of the snippet command might slightly change in a future version (adding > some extra arguments, which might require a small inconsistency). > > Albert > > > On Wed, Aug 31, 2016 at 6:21 PM, Dominic Amann <dom...@gm...> > wrote: > >> Here is the Doxygen comment that produces the snippet: >> >> # To demonstrate the API, take a look at the transducer_setup method of >> # the app class (in pyscope_any.py) below: >> # >> # \snippet this transducer setup >> # >> # multiMode must be set to 4 to support multiple transducers (0 for >> legacy mode). >> >> >> Here is the snippet as produced (seen in my browser). >> >> ==== >> >> To demonstrate the API, take a look at the transducer_setup method of the >> app class (in pyscope_any.py) below: >> 1 def transducer_setup(self): >> 2 tc1 = TraceCollector() >> 3 tc1.on_init() >> 4 settings = TraceCollectorPy.SGprSettings() >> 5 settings.points_per_trace = PPT >> 6 # This may need shifting for different frequencies >> 7 settings.window_timeshift_ps = -42000 >> 8 settings.multiMode = 4 >> 9 # edit tuples in following call for different transducer arrangements >> 10 tc1.prepare_transducers(0, 1, settings, [(1, 1, 1), (2, 2, 1)]) >> 11 # put RX scopes in right slots >> 12 tc1.add_scope(2) >> 13 # add our new trace-collector to list >> 14 self._trace_collectors.append(tc1) >> >> multiMode must be set to 4 to support multiple transducers (0 for legacy >> mode). >> >> ==== >> >> Ideally, the line numbers would be 325..338 (the actual line numbers >> within the code). >> >> >> >> On 31 August 2016 at 11:56, Albert <alb...@gm...> wrote: >> >>> Dominic, >>> >>> There are at the moment, as far as I know, no possibilities to do this, >>> best is to file a bug report for an enhancement at bugzilla (see: >>> http://www.stack.nl/~dimitri/doxygen/manual/trouble.html#bug_reports). >>> Which version of doxygen ar you using and which output format? >>> Where do you see the line numbers? >>> >>> Albert >>> >>> On Wed, Aug 31, 2016 at 5:11 PM, Dominic Amann <dom...@gm...> >>> wrote: >>> >>>> Is there a way to number the code snippet lines with their absolute >>>> (file based) line numbers? I am including the snippet to show other >>>> developers where to look in the code to modify certain values, and the "1" >>>> based line numbers are not helpful. >>>> >>>> If there is no way to do this, then I would like to request this as a >>>> feature. >>>> >>>> -- >>>> >>>> >>>> >>>> People are generally better persuaded by the reasons which they have >>>> themselves discovered than by those which have come into the mind of others >>>> - Blaise Pascal. >>>> >>>> Dominic Amann >>>> M 416-270-4587 >>>> >>>> ------------------------------------------------------------ >>>> ------------------ >>>> >>>> _______________________________________________ >>>> Doxygen-develop mailing list >>>> Dox...@li... >>>> https://lists.sourceforge.net/lists/listinfo/doxygen-develop >>>> >>>> >>> >> >> >> -- >> >> >> >> People are generally better persuaded by the reasons which they have >> themselves discovered than by those which have come into the mind of others >> - Blaise Pascal. >> >> Dominic Amann >> M 416-270-4587 >> > > -- People are generally better persuaded by the reasons which they have themselves discovered than by those which have come into the mind of others - Blaise Pascal. Dominic Amann M 416-270-4587 |
From: Albert <alb...@gm...> - 2016-08-31 16:56:08
|
Dominic, I can reproduce it with python code, the small test I ran before used C code and didn't show the line numbers, so we have a second problem here. We have to dive into these problems, please submit bug reports for it. Note: you use as snippet identification transducer setup which is at the moment fully correct, but please use transducer_setup as the definition of the snippet command might slightly change in a future version (adding some extra arguments, which might require a small inconsistency). Albert On Wed, Aug 31, 2016 at 6:21 PM, Dominic Amann <dom...@gm...> wrote: > Here is the Doxygen comment that produces the snippet: > > # To demonstrate the API, take a look at the transducer_setup method of > # the app class (in pyscope_any.py) below: > # > # \snippet this transducer setup > # > # multiMode must be set to 4 to support multiple transducers (0 for > legacy mode). > > > Here is the snippet as produced (seen in my browser). > > ==== > > To demonstrate the API, take a look at the transducer_setup method of the > app class (in pyscope_any.py) below: > 1 def transducer_setup(self): > 2 tc1 = TraceCollector() > 3 tc1.on_init() > 4 settings = TraceCollectorPy.SGprSettings() > 5 settings.points_per_trace = PPT > 6 # This may need shifting for different frequencies > 7 settings.window_timeshift_ps = -42000 > 8 settings.multiMode = 4 > 9 # edit tuples in following call for different transducer arrangements > 10 tc1.prepare_transducers(0, 1, settings, [(1, 1, 1), (2, 2, 1)]) > 11 # put RX scopes in right slots > 12 tc1.add_scope(2) > 13 # add our new trace-collector to list > 14 self._trace_collectors.append(tc1) > > multiMode must be set to 4 to support multiple transducers (0 for legacy > mode). > > ==== > > Ideally, the line numbers would be 325..338 (the actual line numbers > within the code). > > > > On 31 August 2016 at 11:56, Albert <alb...@gm...> wrote: > >> Dominic, >> >> There are at the moment, as far as I know, no possibilities to do this, >> best is to file a bug report for an enhancement at bugzilla (see: >> http://www.stack.nl/~dimitri/doxygen/manual/trouble.html#bug_reports). >> Which version of doxygen ar you using and which output format? >> Where do you see the line numbers? >> >> Albert >> >> On Wed, Aug 31, 2016 at 5:11 PM, Dominic Amann <dom...@gm...> >> wrote: >> >>> Is there a way to number the code snippet lines with their absolute >>> (file based) line numbers? I am including the snippet to show other >>> developers where to look in the code to modify certain values, and the "1" >>> based line numbers are not helpful. >>> >>> If there is no way to do this, then I would like to request this as a >>> feature. >>> >>> -- >>> >>> >>> >>> People are generally better persuaded by the reasons which they have >>> themselves discovered than by those which have come into the mind of others >>> - Blaise Pascal. >>> >>> Dominic Amann >>> M 416-270-4587 >>> >>> ------------------------------------------------------------ >>> ------------------ >>> >>> _______________________________________________ >>> Doxygen-develop mailing list >>> Dox...@li... >>> https://lists.sourceforge.net/lists/listinfo/doxygen-develop >>> >>> >> > > > -- > > > > People are generally better persuaded by the reasons which they have > themselves discovered than by those which have come into the mind of others > - Blaise Pascal. > > Dominic Amann > M 416-270-4587 > |
From: Dominic A. <dom...@gm...> - 2016-08-31 16:21:45
|
Here is the Doxygen comment that produces the snippet: # To demonstrate the API, take a look at the transducer_setup method of # the app class (in pyscope_any.py) below: # # \snippet this transducer setup # # multiMode must be set to 4 to support multiple transducers (0 for legacy mode). Here is the snippet as produced (seen in my browser). ==== To demonstrate the API, take a look at the transducer_setup method of the app class (in pyscope_any.py) below: 1 def transducer_setup(self): 2 tc1 = TraceCollector() 3 tc1.on_init() 4 settings = TraceCollectorPy.SGprSettings() 5 settings.points_per_trace = PPT 6 # This may need shifting for different frequencies 7 settings.window_timeshift_ps = -42000 8 settings.multiMode = 4 9 # edit tuples in following call for different transducer arrangements 10 tc1.prepare_transducers(0, 1, settings, [(1, 1, 1), (2, 2, 1)]) 11 # put RX scopes in right slots 12 tc1.add_scope(2) 13 # add our new trace-collector to list 14 self._trace_collectors.append(tc1) multiMode must be set to 4 to support multiple transducers (0 for legacy mode). ==== Ideally, the line numbers would be 325..338 (the actual line numbers within the code). On 31 August 2016 at 11:56, Albert <alb...@gm...> wrote: > Dominic, > > There are at the moment, as far as I know, no possibilities to do this, > best is to file a bug report for an enhancement at bugzilla (see: > http://www.stack.nl/~dimitri/doxygen/manual/trouble.html#bug_reports). > Which version of doxygen ar you using and which output format? > Where do you see the line numbers? > > Albert > > On Wed, Aug 31, 2016 at 5:11 PM, Dominic Amann <dom...@gm...> > wrote: > >> Is there a way to number the code snippet lines with their absolute (file >> based) line numbers? I am including the snippet to show other developers >> where to look in the code to modify certain values, and the "1" based line >> numbers are not helpful. >> >> If there is no way to do this, then I would like to request this as a >> feature. >> >> -- >> >> >> >> People are generally better persuaded by the reasons which they have >> themselves discovered than by those which have come into the mind of others >> - Blaise Pascal. >> >> Dominic Amann >> M 416-270-4587 >> >> ------------------------------------------------------------ >> ------------------ >> >> _______________________________________________ >> Doxygen-develop mailing list >> Dox...@li... >> https://lists.sourceforge.net/lists/listinfo/doxygen-develop >> >> > -- People are generally better persuaded by the reasons which they have themselves discovered than by those which have come into the mind of others - Blaise Pascal. Dominic Amann M 416-270-4587 |
From: Albert <alb...@gm...> - 2016-08-31 15:57:00
|
Dominic, There are at the moment, as far as I know, no possibilities to do this, best is to file a bug report for an enhancement at bugzilla (see: http://www.stack.nl/~dimitri/doxygen/manual/trouble.html#bug_reports). Which version of doxygen ar you using and which output format? Where do you see the line numbers? Albert On Wed, Aug 31, 2016 at 5:11 PM, Dominic Amann <dom...@gm...> wrote: > Is there a way to number the code snippet lines with their absolute (file > based) line numbers? I am including the snippet to show other developers > where to look in the code to modify certain values, and the "1" based line > numbers are not helpful. > > If there is no way to do this, then I would like to request this as a > feature. > > -- > > > > People are generally better persuaded by the reasons which they have > themselves discovered than by those which have come into the mind of others > - Blaise Pascal. > > Dominic Amann > M 416-270-4587 > > ------------------------------------------------------------ > ------------------ > > _______________________________________________ > Doxygen-develop mailing list > Dox...@li... > https://lists.sourceforge.net/lists/listinfo/doxygen-develop > > |
From: Dominic A. <dom...@gm...> - 2016-08-31 15:11:26
|
Is there a way to number the code snippet lines with their absolute (file based) line numbers? I am including the snippet to show other developers where to look in the code to modify certain values, and the "1" based line numbers are not helpful. If there is no way to do this, then I would like to request this as a feature. -- People are generally better persuaded by the reasons which they have themselves discovered than by those which have come into the mind of others - Blaise Pascal. Dominic Amann M 416-270-4587 |
From: Philipp E. <phi...@ke...> - 2016-06-21 09:08:51
|
Hello, I am looking for a way to extend copydoc to only copy descriptions for parameter, which are present in the function where the documentation is copied to. So instead of a "argument .. of command @param is not found in the argument list of .." warning I'd like to remove this specific param documentation. Alternatively, I would be happy with an option to remove a param statement from the documentation. Something along the line: \copydoc Foo::bar(bar1, bar2) \rmparam bar2 I tried hijacking parseCopyDoc() in docparser.cpp, but this doesn't look promising. At the end it should be something like this: while(..) { tk = copyDocString.nextToken(); if( !checkArgumentName(tk, tk.isParam()) ) //check argument name was modified to return false in case of the above error. toBeRemovedTokens.add(tk); } // remove tokens from copyDocString Do you have any hints, how to best achieve this? Or could you point me to a good place in the code for this? Cheers, Philipp |
From: Stefan D. <st...@sd...> - 2016-05-30 10:32:56
|
Hi everyone, I am using doxygen to document my VHDL code, and I activated the "UML_LOOK = YES" option, to generate UML style diagrams. I noticed, that the Libraries (like "ieee") and Use Clauses (like std_logic_1164) are listed as public members in the diagrams (see attached image, or github project, below). In my opinion they should be treated like "#include" statements in C. I have provided an example project here: https://github.com/StefanD986/doxygen_vhdl_bug_example You don't need any vhdl compiler to test it. Just clone and build the doxygen documentation in doc/. -- Stefan |
From: Li.Bin(李斌) <li...@ko...> - 2016-04-27 08:29:13
|
Hi all, We implement a new language named CAR (Component Assembly Runtime, http://elastos.org/), which has a similar grammar with the traditional IDL. Is there a tutorial or suggestion to implement the new language support? Thanks a lot. |
From: Petr P. <pet...@se...> - 2016-01-07 14:53:42
|
Hello developers, a fix to the following minor bugs would be most appreciated: #1: If a module IS NOT documented its members still appear in the "File Reference" page. #2: If a module IS documented but the file itself is not the module still appears in the "Modules List" page and "Module Reference" page. I am including minimum working examples (Fortran). Best regards, Petr Parik P.S. If a module is documented but some of its members are not, should those undocumented members be included in the "Module Reference" page when EXTRACT_ALL = NO ? |
From: Adrian M N. <gr...@gm...> - 2015-12-15 11:11:20
|
On Thu, Dec 3, 2015 at 10:34 PM, Gautier <ga...@da...> wrote: > Hi list; > > As stated on Github[1], I would like to add an option behaving similarly > to compilers' -Werror option: any warning generated during Doxygen > execution will abort it immediately. > > This option is, in my opinion, valuable to keep documentation up-to-date > with code changes, specially when multiple people are working altogether. > I will not blame anyone to not think all consequence of a code change, > but scripts can help him/her from breaking anything: > > * strict compiler options (-Werror, -Wall, etc.) prevents at least some > quick&dirty code and obvious bugs. Compilers will warn beginners about > code which will not work (out of bounds errors, etc.), but most of the > time it's simply about a typo / useless dead code. > * Git hook preventing users from pushing invalid commits [2]. We are > intensively using git submodules for instance - it's quite easy to push > an invalid submodule reference to git: > * if you forgot to run "git submodule update --recursive" after > pulling remote changes following by a "git commit -a", leading to > unwilling submodule downgrading. > * if you're referencing a new submodule revision... which you > forgot to push first! > * To have better code consistency, following a single code style using > clang-format[3], similarly to what systemd does[4]. +1 This also helps in case the INPUT directory is invalid. Right now you get: warning: source SOME_PATH is not a readable file or directory... skipping. For a single project, it's easy to spot the invalid INPUT, but for large/er projects you're back to grep-in for "warning:" |
From: John O. <jo...@ly...> - 2015-12-11 15:26:50
|
Hi, I know I jump into the middle of a heated discussion here, but I feel I must chime in and lend Gautier my support. What he suggests sounds very reasonable to me. For instance when writing standard make files by hand (yes people still do this and for a number of reasons) it is easier to check for return code of doxygen than to parse a file and do actions depending on the contents of a file... Also I agree with him that errors are indeed errors and an error should abort just like it does with a C compiler. Thus, you need to either reclassify those errors that should not result in an aborted build as a warning or retain them as errors and abort the build. Fatal errors should be very rare, more like internal non recoverable error states... And yes, a "treat warnings as errors" option is indeed needed. Now I have said what I wanted to say and will go back to lurking. ;-) /John ---- Gautier Pelloux-Prayer <ga...@da...> wrote ---- >Hello again, > >> On 09 Dec 2015, at 19:33, Albert <alb...@gm...> wrote: >> >> Hi Gautier, >> >> Thanks for you responses to my suggestions. >> 1) continuation on errors. >> In principle I think you are right, though the word error has a higher "visibility" than warning. An example where an error is given but the process continues is when the image from the PROJECT_LOGO does not exist. This significantly influences the output. >> So maybe either we should have some more categories: >> - fatal same as current error ans stop generation (will break some builds as some people , I do it myself, search for the word 'error' at the beginning of the sentence >> - error same as current error, but process is continuing >> - warning as it is now >I actually disagree with that point of view; either these are errors which will break the build, either these won't and they should be warnings then. But I would agree with you if "fatal error" were named "exceptions": 3 terms, 3 behaviours. Anyway that's not that important. >> 2) extra exit code for warnings >> I see you objection that it possibly will break, from the compatibility point of view is probably a less good idea >To me it's fine and I think it should - those who do not check doxygen success can easily fix their build system anyway, while it let other users (=at least me) fix doxygen generation instead. >Should I do another patch for that one? > >> 3) Proposed patch does stop at first warning, my idea was more replacing the word "warning" by "error" for higher "visibility". >Yes OK. But would this patch be merged if 2) is done? > >> 4) giving warnings and errors a number >> we agree on this >> 5) inspecting the warnings.log file >> I think in any case one uses a build system to build the code and in one way or another the build errors will be reported as well., possibly by an external tool as well. >> Checking the warnings.log file would only be a test whether or not the warnings file is empty or not, displaying the warnings and abort the build process. So I don't see this as a big problem all build systems will support something like this. >Well it depends on your build process, but when you're building various distincts platform (windows / macosx / unix), there are almost no standard tools to manipule files. And again, if doxygen directly tells us if everything is OK, it avoids an unnecessary extra work IMO. > >> >> Albert >> >> >> >> On Tue, Dec 8, 2015 at 10:35 AM, Gautier Pelloux-Prayer <ga...@da...> wrote: >> Hi Albert, >> >> Thanks for your detailled opinion. Please see my inlined remarks below. >> >> Gautier >> >>> On 06 Dec 2015, at 12:03, Albert <alb...@gm...> wrote: >>> >>> In principle all the errors and warnings doxygen gives should be removed by the engineers. >>> >>> Doxygen distinguish between errors and warnings, where errors possibly corrupt the documentation building or are serious enough, in the eyes of the doxygen developers to stop the generation of the documentation. In case of an error the doxygen developer can also choose to give an error message but to continue anyway. >> Should not it be a warning then? An error should have a consistent behavior during all processing, should it not? >>> >>> When we would have the possibility to promote all the warnings to errors (and we should also stop at all errors that currently don't stop), it would mean that, when using the option, after each error a rerun is necessary. I think this is a bit overdone. >> Well, that's the current behavior of -Werror for compilers. Indeed on first execution you will have a lot of stop&retry, but once it is done, you should not have many errors. And on first execution, you can temporary use -Wno-error to see all errors immediately if needed. >>> I see some possibilities: >>> - in case doxygen discovers warnings it does not finish with exit code 0 but with e.g. exit code 2 (and use exit code 1 for the errors on which it now already stops). >> This solution suits me but if that possibility is adopted it might break many build systems where doxygen is expected to exit successfully in any case. Would it be a problem? >>> - when using the proposed option the message is given as an error, but the process does not stop. I don't see this as an improvement as one can now catch the warnings in a log file and check them. >> I am not sure to understand what do you mean there - proposed patch should exit on first warning? >>> - all warnings get a number and the user can "promote" in the Doxyfile some warnings to, fatal, errors. This would be quite a big effort as all the messages have to be categorized (I've been thinking about this some time ago, but have not started to implement this as it is a lot of work and does not bring enough in my opinion, a quick estimation 700 messages to be checked). >> Well, I agree with you that it would be both an ideal solution and a big effort which does not bring enough ;-). >>> >>> The procedure I follow more or less is: Each time I'm building (overnight builds) the software I catch the warnings and errors in a warnings.log file. When this warnings.log file contains a message (or a new message compared to the last time the build was done) an email is send to the engineer who, last. changed the source file. >> That's the step I want to avoid: having an external script/tool checking doxygen output to see if anything went wrong, while doxygen could tell me directly if I broke something. However this is more or less what I am aiming for. >>> >>> >>> Albert >>> >>> On Thu, Dec 3, 2015 at 9:34 PM, Gautier <ga...@da...> wrote: >>> Hi list; >>> >>> As stated on Github[1], I would like to add an option behaving similarly >>> to compilers' -Werror option: any warning generated during Doxygen >>> execution will abort it immediately. >>> >>> This option is, in my opinion, valuable to keep documentation up-to-date >>> with code changes, specially when multiple people are working altogether. >>> I will not blame anyone to not think all consequence of a code change, >>> but scripts can help him/her from breaking anything: >>> >>> * strict compiler options (-Werror, -Wall, etc.) prevents at least some >>> quick&dirty code and obvious bugs. Compilers will warn beginners about >>> code which will not work (out of bounds errors, etc.), but most of the >>> time it's simply about a typo / useless dead code. >>> * Git hook preventing users from pushing invalid commits [2]. We are >>> intensively using git submodules for instance - it's quite easy to push >>> an invalid submodule reference to git: >>> * if you forgot to run "git submodule update --recursive" after >>> pulling remote changes following by a "git commit -a", leading to >>> unwilling submodule downgrading. >>> * if you're referencing a new submodule revision... which you >>> forgot to push first! >>> * To have better code consistency, following a single code style using >>> clang-format[3], similarly to what systemd does[4]. >>> >>> I think that all of us already encountered one or several of these >>> issues at least once ;-). Having tools checking these errors >>> automatically allow me not to worry about it anymore. >>> Our documentation contains nowadays many errors simply because Doxygen >>> let us do that and we did not look at """inoffensive""" warnings, since >>> they are not preventing us from continuing - they are lost in the >>> verbosity of build logs. >>> >>> I am the only one which would like such an option, and if so: how do you >>> keep your documentation up-to-date? >>> >>> Cheers, >>> >>> Gautier >>> >>> [1] https://github.com/doxygen/doxygen/pull/412 >>> [2] https://gist.github.com/bagage/bdca3d4b66d43db7a5e3 >>> [3] http://clang.llvm.org/docs/ClangFormat.html >>> [4] https://github.com/systemd/systemd/blob/master/autogen.sh >>> >>> ------------------------------------------------------------------------------ >>> Go from Idea to Many App Stores Faster with Intel(R) XDK >>> Give your users amazing mobile app experiences with Intel(R) XDK. >>> Use one codebase in this all-in-one HTML5 development environment. >>> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. >>> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 >>> _______________________________________________ >>> Doxygen-develop mailing list >>> Dox...@li... >>> https://lists.sourceforge.net/lists/listinfo/doxygen-develop >>> >> >> > > >------------------------------------------------------------------------------ >_______________________________________________ >Doxygen-develop mailing list >Dox...@li... >https://lists.sourceforge.net/lists/listinfo/doxygen-develop |
From: Gautier Pelloux-P. <ga...@da...> - 2015-12-10 16:36:58
|
Hello again, > On 09 Dec 2015, at 19:33, Albert <alb...@gm...> wrote: > > Hi Gautier, > > Thanks for you responses to my suggestions. > 1) continuation on errors. > In principle I think you are right, though the word error has a higher "visibility" than warning. An example where an error is given but the process continues is when the image from the PROJECT_LOGO does not exist. This significantly influences the output. > So maybe either we should have some more categories: > - fatal same as current error ans stop generation (will break some builds as some people , I do it myself, search for the word 'error' at the beginning of the sentence > - error same as current error, but process is continuing > - warning as it is now I actually disagree with that point of view; either these are errors which will break the build, either these won't and they should be warnings then. But I would agree with you if "fatal error" were named "exceptions": 3 terms, 3 behaviours. Anyway that's not that important. > 2) extra exit code for warnings > I see you objection that it possibly will break, from the compatibility point of view is probably a less good idea To me it's fine and I think it should - those who do not check doxygen success can easily fix their build system anyway, while it let other users (=at least me) fix doxygen generation instead. Should I do another patch for that one? > 3) Proposed patch does stop at first warning, my idea was more replacing the word "warning" by "error" for higher "visibility". Yes OK. But would this patch be merged if 2) is done? > 4) giving warnings and errors a number > we agree on this > 5) inspecting the warnings.log file > I think in any case one uses a build system to build the code and in one way or another the build errors will be reported as well., possibly by an external tool as well. > Checking the warnings.log file would only be a test whether or not the warnings file is empty or not, displaying the warnings and abort the build process. So I don't see this as a big problem all build systems will support something like this. Well it depends on your build process, but when you're building various distincts platform (windows / macosx / unix), there are almost no standard tools to manipule files. And again, if doxygen directly tells us if everything is OK, it avoids an unnecessary extra work IMO. > > Albert > > > > On Tue, Dec 8, 2015 at 10:35 AM, Gautier Pelloux-Prayer <ga...@da...> wrote: > Hi Albert, > > Thanks for your detailled opinion. Please see my inlined remarks below. > > Gautier > >> On 06 Dec 2015, at 12:03, Albert <alb...@gm...> wrote: >> >> In principle all the errors and warnings doxygen gives should be removed by the engineers. >> >> Doxygen distinguish between errors and warnings, where errors possibly corrupt the documentation building or are serious enough, in the eyes of the doxygen developers to stop the generation of the documentation. In case of an error the doxygen developer can also choose to give an error message but to continue anyway. > Should not it be a warning then? An error should have a consistent behavior during all processing, should it not? >> >> When we would have the possibility to promote all the warnings to errors (and we should also stop at all errors that currently don't stop), it would mean that, when using the option, after each error a rerun is necessary. I think this is a bit overdone. > Well, that's the current behavior of -Werror for compilers. Indeed on first execution you will have a lot of stop&retry, but once it is done, you should not have many errors. And on first execution, you can temporary use -Wno-error to see all errors immediately if needed. >> I see some possibilities: >> - in case doxygen discovers warnings it does not finish with exit code 0 but with e.g. exit code 2 (and use exit code 1 for the errors on which it now already stops). > This solution suits me but if that possibility is adopted it might break many build systems where doxygen is expected to exit successfully in any case. Would it be a problem? >> - when using the proposed option the message is given as an error, but the process does not stop. I don't see this as an improvement as one can now catch the warnings in a log file and check them. > I am not sure to understand what do you mean there - proposed patch should exit on first warning? >> - all warnings get a number and the user can "promote" in the Doxyfile some warnings to, fatal, errors. This would be quite a big effort as all the messages have to be categorized (I've been thinking about this some time ago, but have not started to implement this as it is a lot of work and does not bring enough in my opinion, a quick estimation 700 messages to be checked). > Well, I agree with you that it would be both an ideal solution and a big effort which does not bring enough ;-). >> >> The procedure I follow more or less is: Each time I'm building (overnight builds) the software I catch the warnings and errors in a warnings.log file. When this warnings.log file contains a message (or a new message compared to the last time the build was done) an email is send to the engineer who, last. changed the source file. > That's the step I want to avoid: having an external script/tool checking doxygen output to see if anything went wrong, while doxygen could tell me directly if I broke something. However this is more or less what I am aiming for. >> >> >> Albert >> >> On Thu, Dec 3, 2015 at 9:34 PM, Gautier <ga...@da...> wrote: >> Hi list; >> >> As stated on Github[1], I would like to add an option behaving similarly >> to compilers' -Werror option: any warning generated during Doxygen >> execution will abort it immediately. >> >> This option is, in my opinion, valuable to keep documentation up-to-date >> with code changes, specially when multiple people are working altogether. >> I will not blame anyone to not think all consequence of a code change, >> but scripts can help him/her from breaking anything: >> >> * strict compiler options (-Werror, -Wall, etc.) prevents at least some >> quick&dirty code and obvious bugs. Compilers will warn beginners about >> code which will not work (out of bounds errors, etc.), but most of the >> time it's simply about a typo / useless dead code. >> * Git hook preventing users from pushing invalid commits [2]. We are >> intensively using git submodules for instance - it's quite easy to push >> an invalid submodule reference to git: >> * if you forgot to run "git submodule update --recursive" after >> pulling remote changes following by a "git commit -a", leading to >> unwilling submodule downgrading. >> * if you're referencing a new submodule revision... which you >> forgot to push first! >> * To have better code consistency, following a single code style using >> clang-format[3], similarly to what systemd does[4]. >> >> I think that all of us already encountered one or several of these >> issues at least once ;-). Having tools checking these errors >> automatically allow me not to worry about it anymore. >> Our documentation contains nowadays many errors simply because Doxygen >> let us do that and we did not look at """inoffensive""" warnings, since >> they are not preventing us from continuing - they are lost in the >> verbosity of build logs. >> >> I am the only one which would like such an option, and if so: how do you >> keep your documentation up-to-date? >> >> Cheers, >> >> Gautier >> >> [1] https://github.com/doxygen/doxygen/pull/412 >> [2] https://gist.github.com/bagage/bdca3d4b66d43db7a5e3 >> [3] http://clang.llvm.org/docs/ClangFormat.html >> [4] https://github.com/systemd/systemd/blob/master/autogen.sh >> >> ------------------------------------------------------------------------------ >> Go from Idea to Many App Stores Faster with Intel(R) XDK >> Give your users amazing mobile app experiences with Intel(R) XDK. >> Use one codebase in this all-in-one HTML5 development environment. >> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. >> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 >> _______________________________________________ >> Doxygen-develop mailing list >> Dox...@li... >> https://lists.sourceforge.net/lists/listinfo/doxygen-develop >> > > |
From: Albert <alb...@gm...> - 2015-12-09 18:33:16
|
Hi Gautier, Thanks for you responses to my suggestions. 1) continuation on errors. In principle I think you are right, though the word error has a higher "visibility" than warning. An example where an error is given but the process continues is when the image from the PROJECT_LOGO does not exist. This significantly influences the output. So maybe either we should have some more categories: - fatal same as current error ans stop generation (will break some builds as some people , I do it myself, search for the word 'error' at the beginning of the sentence - error same as current error, but process is continuing - warning as it is now 2) extra exit code for warnings I see you objection that it possibly will break, from the compatibility point of view is probably a less good idea 3) Proposed patch does stop at first warning, my idea was more replacing the word "warning" by "error" for higher "visibility". 4) giving warnings and errors a number we agree on this 5) inspecting the warnings.log file I think in any case one uses a build system to build the code and in one way or another the build errors will be reported as well., possibly by an external tool as well. Checking the warnings.log file would only be a test whether or not the warnings file is empty or not, displaying the warnings and abort the build process. So I don't see this as a big problem all build systems will support something like this. Albert On Tue, Dec 8, 2015 at 10:35 AM, Gautier Pelloux-Prayer <ga...@da...> wrote: > Hi Albert, > > Thanks for your detailled opinion. Please see my inlined remarks below. > > Gautier > > > On 06 Dec 2015, at 12:03, Albert <alb...@gm...> wrote: > > > > In principle all the errors and warnings doxygen gives should be removed > by the engineers. > > > > Doxygen distinguish between errors and warnings, where errors possibly > corrupt the documentation building or are serious enough, in the eyes of > the doxygen developers to stop the generation of the documentation. In case > of an error the doxygen developer can also choose to give an error message > but to continue anyway. > Should not it be a warning then? An error should have a consistent > behavior during all processing, should it not? > > > > When we would have the possibility to promote all the warnings to errors > (and we should also stop at all errors that currently don't stop), it would > mean that, when using the option, after each error a rerun is necessary. I > think this is a bit overdone. > Well, that's the current behavior of -Werror for compilers. Indeed on > first execution you will have a lot of stop&retry, but once it is done, you > should not have many errors. And on first execution, you can temporary use > -Wno-error to see all errors immediately if needed. > > I see some possibilities: > > - in case doxygen discovers warnings it does not finish with exit code 0 > but with e.g. exit code 2 (and use exit code 1 for the errors on which it > now already stops). > This solution suits me but if that possibility is adopted it might break > many build systems where doxygen is expected to exit successfully in any > case. Would it be a problem? > > - when using the proposed option the message is given as an error, but > the process does not stop. I don't see this as an improvement as one can > now catch the warnings in a log file and check them. > I am not sure to understand what do you mean there - proposed patch should > exit on first warning? > > - all warnings get a number and the user can "promote" in the Doxyfile > some warnings to, fatal, errors. This would be quite a big effort as all > the messages have to be categorized (I've been thinking about this some > time ago, but have not started to implement this as it is a lot of work and > does not bring enough in my opinion, a quick estimation 700 messages to be > checked). > Well, I agree with you that it would be both an ideal solution and a big > effort which does not bring enough ;-). > > > > The procedure I follow more or less is: Each time I'm building > (overnight builds) the software I catch the warnings and errors in a > warnings.log file. When this warnings.log file contains a message (or a new > message compared to the last time the build was done) an email is send to > the engineer who, last. changed the source file. > That's the step I want to avoid: having an external script/tool checking > doxygen output to see if anything went wrong, while doxygen could tell me > directly if I broke something. However this is more or less what I am > aiming for. > > > > > > Albert > > > > On Thu, Dec 3, 2015 at 9:34 PM, Gautier <ga...@da...> wrote: > > Hi list; > > > > As stated on Github[1], I would like to add an option behaving similarly > > to compilers' -Werror option: any warning generated during Doxygen > > execution will abort it immediately. > > > > This option is, in my opinion, valuable to keep documentation up-to-date > > with code changes, specially when multiple people are working altogether. > > I will not blame anyone to not think all consequence of a code change, > > but scripts can help him/her from breaking anything: > > > > * strict compiler options (-Werror, -Wall, etc.) prevents at least some > > quick&dirty code and obvious bugs. Compilers will warn beginners about > > code which will not work (out of bounds errors, etc.), but most of the > > time it's simply about a typo / useless dead code. > > * Git hook preventing users from pushing invalid commits [2]. We are > > intensively using git submodules for instance - it's quite easy to push > > an invalid submodule reference to git: > > * if you forgot to run "git submodule update --recursive" after > > pulling remote changes following by a "git commit -a", leading to > > unwilling submodule downgrading. > > * if you're referencing a new submodule revision... which you > > forgot to push first! > > * To have better code consistency, following a single code style using > > clang-format[3], similarly to what systemd does[4]. > > > > I think that all of us already encountered one or several of these > > issues at least once ;-). Having tools checking these errors > > automatically allow me not to worry about it anymore. > > Our documentation contains nowadays many errors simply because Doxygen > > let us do that and we did not look at """inoffensive""" warnings, since > > they are not preventing us from continuing - they are lost in the > > verbosity of build logs. > > > > I am the only one which would like such an option, and if so: how do you > > keep your documentation up-to-date? > > > > Cheers, > > > > Gautier > > > > [1] https://github.com/doxygen/doxygen/pull/412 > > [2] https://gist.github.com/bagage/bdca3d4b66d43db7a5e3 > > [3] http://clang.llvm.org/docs/ClangFormat.html > > [4] https://github.com/systemd/systemd/blob/master/autogen.sh > > > > > ------------------------------------------------------------------------------ > > Go from Idea to Many App Stores Faster with Intel(R) XDK > > Give your users amazing mobile app experiences with Intel(R) XDK. > > Use one codebase in this all-in-one HTML5 development environment. > > Design, debug & build mobile apps & 2D/3D high-impact games for multiple > OSs. > > http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 > > _______________________________________________ > > Doxygen-develop mailing list > > Dox...@li... > > https://lists.sourceforge.net/lists/listinfo/doxygen-develop > > > > |
From: Gautier Pelloux-P. <ga...@da...> - 2015-12-08 09:35:56
|
Hi Albert, Thanks for your detailled opinion. Please see my inlined remarks below. Gautier > On 06 Dec 2015, at 12:03, Albert <alb...@gm...> wrote: > > In principle all the errors and warnings doxygen gives should be removed by the engineers. > > Doxygen distinguish between errors and warnings, where errors possibly corrupt the documentation building or are serious enough, in the eyes of the doxygen developers to stop the generation of the documentation. In case of an error the doxygen developer can also choose to give an error message but to continue anyway. Should not it be a warning then? An error should have a consistent behavior during all processing, should it not? > > When we would have the possibility to promote all the warnings to errors (and we should also stop at all errors that currently don't stop), it would mean that, when using the option, after each error a rerun is necessary. I think this is a bit overdone. Well, that's the current behavior of -Werror for compilers. Indeed on first execution you will have a lot of stop&retry, but once it is done, you should not have many errors. And on first execution, you can temporary use -Wno-error to see all errors immediately if needed. > I see some possibilities: > - in case doxygen discovers warnings it does not finish with exit code 0 but with e.g. exit code 2 (and use exit code 1 for the errors on which it now already stops). This solution suits me but if that possibility is adopted it might break many build systems where doxygen is expected to exit successfully in any case. Would it be a problem? > - when using the proposed option the message is given as an error, but the process does not stop. I don't see this as an improvement as one can now catch the warnings in a log file and check them. I am not sure to understand what do you mean there - proposed patch should exit on first warning? > - all warnings get a number and the user can "promote" in the Doxyfile some warnings to, fatal, errors. This would be quite a big effort as all the messages have to be categorized (I've been thinking about this some time ago, but have not started to implement this as it is a lot of work and does not bring enough in my opinion, a quick estimation 700 messages to be checked). Well, I agree with you that it would be both an ideal solution and a big effort which does not bring enough ;-). > > The procedure I follow more or less is: Each time I'm building (overnight builds) the software I catch the warnings and errors in a warnings.log file. When this warnings.log file contains a message (or a new message compared to the last time the build was done) an email is send to the engineer who, last. changed the source file. That's the step I want to avoid: having an external script/tool checking doxygen output to see if anything went wrong, while doxygen could tell me directly if I broke something. However this is more or less what I am aiming for. > > > Albert > > On Thu, Dec 3, 2015 at 9:34 PM, Gautier <ga...@da...> wrote: > Hi list; > > As stated on Github[1], I would like to add an option behaving similarly > to compilers' -Werror option: any warning generated during Doxygen > execution will abort it immediately. > > This option is, in my opinion, valuable to keep documentation up-to-date > with code changes, specially when multiple people are working altogether. > I will not blame anyone to not think all consequence of a code change, > but scripts can help him/her from breaking anything: > > * strict compiler options (-Werror, -Wall, etc.) prevents at least some > quick&dirty code and obvious bugs. Compilers will warn beginners about > code which will not work (out of bounds errors, etc.), but most of the > time it's simply about a typo / useless dead code. > * Git hook preventing users from pushing invalid commits [2]. We are > intensively using git submodules for instance - it's quite easy to push > an invalid submodule reference to git: > * if you forgot to run "git submodule update --recursive" after > pulling remote changes following by a "git commit -a", leading to > unwilling submodule downgrading. > * if you're referencing a new submodule revision... which you > forgot to push first! > * To have better code consistency, following a single code style using > clang-format[3], similarly to what systemd does[4]. > > I think that all of us already encountered one or several of these > issues at least once ;-). Having tools checking these errors > automatically allow me not to worry about it anymore. > Our documentation contains nowadays many errors simply because Doxygen > let us do that and we did not look at """inoffensive""" warnings, since > they are not preventing us from continuing - they are lost in the > verbosity of build logs. > > I am the only one which would like such an option, and if so: how do you > keep your documentation up-to-date? > > Cheers, > > Gautier > > [1] https://github.com/doxygen/doxygen/pull/412 > [2] https://gist.github.com/bagage/bdca3d4b66d43db7a5e3 > [3] http://clang.llvm.org/docs/ClangFormat.html > [4] https://github.com/systemd/systemd/blob/master/autogen.sh > > ------------------------------------------------------------------------------ > Go from Idea to Many App Stores Faster with Intel(R) XDK > Give your users amazing mobile app experiences with Intel(R) XDK. > Use one codebase in this all-in-one HTML5 development environment. > Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. > http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 > _______________________________________________ > Doxygen-develop mailing list > Dox...@li... > https://lists.sourceforge.net/lists/listinfo/doxygen-develop > |
From: Albert <alb...@gm...> - 2015-12-06 11:03:59
|
In principle all the errors and warnings doxygen gives should be removed by the engineers. Doxygen distinguish between errors and warnings, where errors possibly corrupt the documentation building or are serious enough, in the eyes of the doxygen developers to stop the generation of the documentation. In case of an error the doxygen developer can also choose to give an error message but to continue anyway. When we would have the possibility to promote all the warnings to errors (and we should also stop at all errors that currently don't stop), it would mean that, when using the option, after each error a rerun is necessary. I think this is a bit overdone. I see some possibilities: - in case doxygen discovers warnings it does not finish with exit code 0 but with e.g. exit code 2 (and use exit code 1 for the errors on which it now already stops). - when using the proposed option the message is given as an error, but the process does not stop. I don't see this as an improvement as one can now catch the warnings in a log file and check them. - all warnings get a number and the user can "promote" in the Doxyfile some warnings to, fatal, errors. This would be quite a big effort as all the messages have to be categorized (I've been thinking about this some time ago, but have not started to implement this as it is a lot of work and does not bring enough in my opinion, a quick estimation 700 messages to be checked). The procedure I follow more or less is: Each time I'm building (overnight builds) the software I catch the warnings and errors in a warnings.log file. When this warnings.log file contains a message (or a new message compared to the last time the build was done) an email is send to the engineer who, last. changed the source file. Albert On Thu, Dec 3, 2015 at 9:34 PM, Gautier <ga...@da...> wrote: > Hi list; > > As stated on Github[1], I would like to add an option behaving similarly > to compilers' -Werror option: any warning generated during Doxygen > execution will abort it immediately. > > This option is, in my opinion, valuable to keep documentation up-to-date > with code changes, specially when multiple people are working altogether. > I will not blame anyone to not think all consequence of a code change, > but scripts can help him/her from breaking anything: > > * strict compiler options (-Werror, -Wall, etc.) prevents at least some > quick&dirty code and obvious bugs. Compilers will warn beginners about > code which will not work (out of bounds errors, etc.), but most of the > time it's simply about a typo / useless dead code. > * Git hook preventing users from pushing invalid commits [2]. We are > intensively using git submodules for instance - it's quite easy to push > an invalid submodule reference to git: > * if you forgot to run "git submodule update --recursive" after > pulling remote changes following by a "git commit -a", leading to > unwilling submodule downgrading. > * if you're referencing a new submodule revision... which you > forgot to push first! > * To have better code consistency, following a single code style using > clang-format[3], similarly to what systemd does[4]. > > I think that all of us already encountered one or several of these > issues at least once ;-). Having tools checking these errors > automatically allow me not to worry about it anymore. > Our documentation contains nowadays many errors simply because Doxygen > let us do that and we did not look at """inoffensive""" warnings, since > they are not preventing us from continuing - they are lost in the > verbosity of build logs. > > I am the only one which would like such an option, and if so: how do you > keep your documentation up-to-date? > > Cheers, > > Gautier > > [1] https://github.com/doxygen/doxygen/pull/412 > [2] https://gist.github.com/bagage/bdca3d4b66d43db7a5e3 > [3] http://clang.llvm.org/docs/ClangFormat.html > [4] https://github.com/systemd/systemd/blob/master/autogen.sh > > > ------------------------------------------------------------------------------ > Go from Idea to Many App Stores Faster with Intel(R) XDK > Give your users amazing mobile app experiences with Intel(R) XDK. > Use one codebase in this all-in-one HTML5 development environment. > Design, debug & build mobile apps & 2D/3D high-impact games for multiple > OSs. > http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 > _______________________________________________ > Doxygen-develop mailing list > Dox...@li... > https://lists.sourceforge.net/lists/listinfo/doxygen-develop > |
From: Gautier <ga...@da...> - 2015-12-03 20:35:05
|
Hi list; As stated on Github[1], I would like to add an option behaving similarly to compilers' -Werror option: any warning generated during Doxygen execution will abort it immediately. This option is, in my opinion, valuable to keep documentation up-to-date with code changes, specially when multiple people are working altogether. I will not blame anyone to not think all consequence of a code change, but scripts can help him/her from breaking anything: * strict compiler options (-Werror, -Wall, etc.) prevents at least some quick&dirty code and obvious bugs. Compilers will warn beginners about code which will not work (out of bounds errors, etc.), but most of the time it's simply about a typo / useless dead code. * Git hook preventing users from pushing invalid commits [2]. We are intensively using git submodules for instance - it's quite easy to push an invalid submodule reference to git: * if you forgot to run "git submodule update --recursive" after pulling remote changes following by a "git commit -a", leading to unwilling submodule downgrading. * if you're referencing a new submodule revision... which you forgot to push first! * To have better code consistency, following a single code style using clang-format[3], similarly to what systemd does[4]. I think that all of us already encountered one or several of these issues at least once ;-). Having tools checking these errors automatically allow me not to worry about it anymore. Our documentation contains nowadays many errors simply because Doxygen let us do that and we did not look at """inoffensive""" warnings, since they are not preventing us from continuing - they are lost in the verbosity of build logs. I am the only one which would like such an option, and if so: how do you keep your documentation up-to-date? Cheers, Gautier [1] https://github.com/doxygen/doxygen/pull/412 [2] https://gist.github.com/bagage/bdca3d4b66d43db7a5e3 [3] http://clang.llvm.org/docs/ClangFormat.html [4] https://github.com/systemd/systemd/blob/master/autogen.sh |
From: <c....@po...> - 2015-11-28 10:02:51
|
On 2015-11-18 21:49 <c....@po...> wrote: > Related to <https://bugzilla.gnome.org/show_bug.cgi?id=757509> Am I the only one who can reproduce this error? -- GnuPGP-Key ID 0751A8EC |
From: <c....@po...> - 2015-11-27 23:15:25
|
On 2015-11-18 21:49 <c....@po...> wrote: > Related to <https://bugzilla.gnome.org/show_bug.cgi?id=757509> Am I the only one who can reproduce this error? -- GnuPGP-Key ID 0751A8EC |
From: <c....@po...> - 2015-11-18 20:50:22
|
Related to <https://bugzilla.gnome.org/show_bug.cgi?id=757509> I try to use Doxygen with Python-code. But I have some problems with the inheritance and how this is displayed in the generated docs. I generated documentation with Doxygen (in default configuration) for the code below. But the problem is that a.ABase in the inheritance tree of B-docu is not linkable/clickable. Even when you look at the tree for a.ABase the class B is not shown. This depends on the existence of the __init__.py file. I don't know why. When I delete the __init__.py everything is fine. Can someone check that if it is reproducable? -- GnuPGP-Key ID 0751A8EC |
From: Brilliantov K. V. <bri...@by...> - 2015-08-14 09:14:30
|
Signed-off-by: Brilliantov Kirill Vladimirovich <bri...@by...> --- CMakeLists.txt | 2 +- src/CMakeLists.txt | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 3695093..0b5308c 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -11,7 +11,7 @@ # Documents produced by Doxygen are derivative works derived from the # input used in their production; they are not affected by this license. -cmake_minimum_required(VERSION 2.8.12) +cmake_minimum_required(VERSION 2.8.11) project(doxygen) option(build_wizard "Build the GUI frontend for doxygen." OFF) diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt index 155bf77..4532b97 100644 --- a/src/CMakeLists.txt +++ b/src/CMakeLists.txt @@ -17,8 +17,8 @@ file(GLOB LANGUAGE_FILES "${CMAKE_SOURCE_DIR}/src/translator_??.h") add_definitions(-DYY_BUF_SIZE=262144 -DYY_READ_BUF_SIZE=262144) # generate settings.h -file(GENERATE OUTPUT ${GENERATED_SRC}/settings.h -CONTENT "#ifndef SETTINGS_H +file(WRITE ${GENERATED_SRC}/settings.h +"#ifndef SETTINGS_H #define SETTINGS_H #define USE_SQLITE3 ${sqlite3} #define USE_LIBCLANG ${clang} @@ -31,8 +31,8 @@ set_source_files_properties(${GENERATED_SRC}/settings.h PROPERTIES GENERATED 1) # generate version.cpp -file(GENERATE OUTPUT ${GENERATED_SRC}/version.cpp - CONTENT "char versionString[]=\"${VERSION}\";" +file(WRITE ${GENERATED_SRC}/version.cpp + "char versionString[]=\"${VERSION}\";" ) set_source_files_properties(${GENERATED_SRC}/version.cpp PROPERTIES GENERATED 1) -- 2.1.4 |
From: Kevin M. <dol...@ao...> - 2015-08-02 20:32:04
|
Hello, As a tip for developers new to CMake, I use the following command to build doxygen and the doxywizard with debug symbols that gdb can use: "cmake -G "Unix Makefiles" -Dbuild_wizard=on -DCMAKE_BUILD_TYPE=Debug $OLDPWD" This is a necessity on Fedora to get stack traces from crashers. I think this information should be put in the BUILD.txt file in GIT. - Kevin McBride |