Re: LilyPond C/C++ #include cleanup
On Friday 19 November 2004 14:52, Han-Wen Nienhuys wrote: I've added the Doxygen file to CVS. I'm willing to add doxygen rules to the makefile, if someone writes them. Unfortunately, I'm not proficient with 'autoconf', so I can't provide a working solution right now. But here's what I've got so far and my ideas about how to fill the gaps: (1) Move 'Doxyfile' to 'Documentation/Doxyfile.in' and apply the attached patch; it introduces variables @PACKAGE_NAME@, @TOPLEVEL_VERSION@, and @HAVE_DOT@ at the appropriate locations and it makes 'doxygen' look for input starting at directory '..'. (2) Let the toplevel 'configure.in' check for 'doxygen' and 'dot': STEPMAKE_PROGS(DOXYGEN, doxygen, OPTIONAL, 1.3.8) STEPMAKE_PROGS(DOT, dot, OPTIONAL, 1.16) and set the variable HAVE_DOT to 'YES' if 'dot' is present, otherwise to 'NO'. (3) [I failed to achieve this step; all I managed was to replace PACKAGE_NAME, but not the other two variables] Create 'Documentation/Doxyfile' from 'Documentation/Doxyfile.in' by replacing the @-variables with their current contents, e.g., 'LilyPond', '2.5.0hwn1', and 'YES' resp. 'NO'. (4) In the GNUmakefile for directory Documentation run the command line doxygen Doxyfile, iff DOXYGEN is set in (2). There is no other dependency necessary as soon as the 'Doxyfile' is installed. DOT will be triggered by DOXYGEN only when HAVE_DOT is 'YES'. I'm sure it is not hard to do this, but as I said above, I've never used 'autoconf' and even after some trial, all I got were errors. Andreas Doxyfile.patch.gz Description: GNU Zip compressed data ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
LilyPond C/C++ #include cleanup
[EMAIL PROTECTED] writes: Hello list, Has anyone considered to apply Doxygen to the LilyPond sources? I'm aware that the internal comments are not doxygen'erated, however, Doxygen is capable to analyze plain C/C++ codes and to generate at least rudimentary documentation in various output formats. One of the major advantages is the creation of graphical displays of specific aspects of a bundle of source codes, e.g., class hierarchy, class graphs, and include/included-by graphs. With the tool doxywizard (1.3.9) I have created a rudimentary Doxyfile and run Doxygen over the CVS content of current LilyPond. This definition file is attached to this submission for those who would like to apply Doxygen themselves. Now, when I click through the HTML documentation and look at the images of the include graphs, I find that many #include directives are redundant, i.e., define transitive connections between header a/o source files (plus at least one cyclic dependency between flower/include/string.hh and flower/include/international.hh). It is common knowledge (John Lakos and other experts come to mind) that the #include hierarchy can be an important backbone of a C/C++ software system as well as an elementary entry point to understanding such a system. I've added the Doxygen file to CVS. I'm willing to add doxygen rules to the makefile, if someone writes them. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond C/C++ #include cleanup
Andreas Scherer writes: Has anyone considered to apply Doxygen to the LilyPond sources? See these threads http://lists.gnu.org/archive/html/lilypond-devel/2004-03/msg00226.html http://lists.gnu.org/archive/html/lilypond-devel/2004-04/msg00083.html there were some good intentions, but not much has happened. I'm aware that the internal comments are not doxygen'erated, however, Doxygen is capable to analyze plain C/C++ codes and to generate at least rudimentary documentation in various output formats. As Han-Wen said, a docstring mechanism would be preferrable, but doxygen doc is better than nothing -- if it can offer some basic quality. Now, when I click through the HTML documentation and look at the images of the include graphs, I find that many #include directives are redundant, Thanks for looking into this. If there is interest in this group for such an improvement of the C/C++ sources of LilyPond, I would volunteer to make the necessary modifications, i.e., to remove the superfluous #include directives, while guaranteeing the correct compilability of the system. Any comments? That would be great. Make sure to use latest CVS and send unified diffs, (cvs diff -u). Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond C/C++ #include cleanup
Jan Nieuwenhuizen writes: there were some good intentions, but not much has happened. Apart from Carl Sorensen, who started a programming concepts document http://lists.gnu.org/archive/html/lilypond-devel/2004-10/msg00241.html which is not the same thing, but it's related. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
LilyPond C/C++ #include cleanup
Hello list, Has anyone considered to apply Doxygen to the LilyPond sources? I'm aware that the internal comments are not doxygen'erated, however, Doxygen is capable to analyze plain C/C++ codes and to generate at least rudimentary documentation in various output formats. One of the major advantages is the creation of graphical displays of specific aspects of a bundle of source codes, e.g., class hierarchy, class graphs, and include/included-by graphs. With the tool doxywizard (1.3.9) I have created a rudimentary Doxyfile and run Doxygen over the CVS content of current LilyPond. This definition file is attached to this submission for those who would like to apply Doxygen themselves. Now, when I click through the HTML documentation and look at the images of the include graphs, I find that many #include directives are redundant, i.e., define transitive connections between header a/o source files (plus at least one cyclic dependency between flower/include/string.hh and flower/include/international.hh). It is common knowledge (John Lakos and other experts come to mind) that the #include hierarchy can be an important backbone of a C/C++ software system as well as an elementary entry point to understanding such a system. If there is interest in this group for such an improvement of the C/C++ sources of LilyPond, I would volunteer to make the necessary modifications, i.e., to remove the superfluous #include directives, while guaranteeing the correct compilability of the system. Any comments? Cheers, Andreas Doxyfile.gz Description: GNU Zip compressed data ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
