Thread: [Doxygen-develop] Problem with default values
Brought to you by:
dimitri
Menu
▾
▴
doxygen-develop
|
From: Robert D. <rcd...@gm...> - 2013-06-03 20:33:31
|
Hi,
I'm adding some new config options to Doxygen. Here is my code:
cs = cfg->addString(
"WARN_STRING",
"The string that is prefixed to each warning that
will be printed."
);
cs->setDefaultValue("Warning: ");
Notice I have a trailing space after the colon for the default value.
I noticed that after ConfigString::substEnvVars() is called, this
space is removed. I'd like to be able to keep the spaces in the
default value. How can I do this?
|
|
From: Doxygen <do...@gm...> - 2013-06-03 20:51:55
|
Hi Robert,
On 3 jun. 2013, at 22:33, Robert Dailey <rcd...@gm...> wrote:
> Hi,
>
> I'm adding some new config options to Doxygen. Here is my code:
>
>
> cs = cfg->addString(
> "WARN_STRING",
> "The string that is prefixed to each warning that
> will be printed."
> );
> cs->setDefaultValue("Warning: ");
Please add new options to config.xml not to configoptions.cpp which is generated from it.
>
> Notice I have a trailing space after the colon for the default value.
> I noticed that after ConfigString::substEnvVars() is called, this
> space is removed. I'd like to be able to keep the spaces in the
> default value. How can I do this?
I guess we should fix substEnvVars not to strip the space...
Regards,
Dimitri
|
|
From: Robert D. <rcd...@gm...> - 2013-06-03 21:01:41
|
Thanks for the information guys, I'm still learning the code base. I submitted a patch here to add some new config variables: https://bugzilla.gnome.org/show_bug.cgi?id=701550 However, I need to re-post the patch with changes to the XML file instead. Will the VS9 project re-generate the file for me? Please let me know what else I'm doing wrong in the patch so I can correct it. Thanks again guys. On Mon, Jun 3, 2013 at 3:51 PM, Doxygen <do...@gm...> wrote: > Hi Robert, > > On 3 jun. 2013, at 22:33, Robert Dailey <rcd...@gm...> wrote: > >> Hi, >> >> I'm adding some new config options to Doxygen. Here is my code: >> >> >> cs = cfg->addString( >> "WARN_STRING", >> "The string that is prefixed to each warning that >> will be printed." >> ); >> cs->setDefaultValue("Warning: "); > > Please add new options to config.xml not to configoptions.cpp which is generated from it. > >> >> Notice I have a trailing space after the colon for the default value. >> I noticed that after ConfigString::substEnvVars() is called, this >> space is removed. I'd like to be able to keep the spaces in the >> default value. How can I do this? > > I guess we should fix substEnvVars not to strip the space... > > Regards, > Dimitri > |
|
From: Robert D. <rcd...@gm...> - 2013-06-03 21:13:55
|
On Mon, Jun 3, 2013 at 4:01 PM, Robert Dailey <rcd...@gm...> wrote: > Thanks for the information guys, I'm still learning the code base. I > submitted a patch here to add some new config variables: > https://bugzilla.gnome.org/show_bug.cgi?id=701550 > > However, I need to re-post the patch with changes to the XML file > instead. Will the VS9 project re-generate the file for me? Please let > me know what else I'm doing wrong in the patch so I can correct it. > Thanks again guys. Ok, I took a lucky guess on generating the file. I ran: configgen.py config.xml > configoptions.cpp I notice however that the description string isn't manually word-wrapped like the other options. Here is my new XML code: <option type='string' id='WARN_STRING' format='string' docs=' The string that is prefixed to each warning that will be printed. A space is automatically placed between the prefix and the message that follows. ' defval='Warning:'/> <option type='string' id='ERROR_STRING' format='string' docs=' The string that is prefixed to each error that will be printed. A space is automatically placed between the prefix and the message that follows. ' defval='Error:'/> And the code output is: //---- cs = cfg->addString( "WARN_STRING", "The string that is prefixed to each warning that will be printed. A space is automatically placed between the prefix and the message that follows." ); cs->setDefaultValue("Warning:"); //---- cs = cfg->addString( "ERROR_STRING", "The string that is prefixed to each error that will be printed. A space is automatically placed between the prefix and the message that follows." ); cs->setDefaultValue("Error:"); Since I'm sending plain text email, the mail server probably word wraps my code snippets so you won't be able to see the effects. But notice no literal '\n' in the string... |
|
From: Philipp M. <phi...@ge...> - 2013-06-04 01:34:46
|
Robert Dailey <rcd...@gm...> writes:
> Hi,
>
> I'm adding some new config options to Doxygen. Here is my code:
>
>
> cs = cfg->addString(
> "WARN_STRING",
> "The string that is prefixed to each warning that
> will be printed."
> );
> cs->setDefaultValue("Warning: ");
>
> Notice I have a trailing space after the colon for the default value.
> I noticed that after ConfigString::substEnvVars() is called, this
> space is removed. I'd like to be able to keep the spaces in the
> default value. How can I do this?
The responsible code for stripping is in line 2843 in config.cpp. The
whole substitution process seems a little bit awkward and fixing it
might be more involved.
NB: To add a config variable you need to add it to the config.xml file
and not to the configoptions.cpp file. Don't forget to rerun
configgen.py. It is really unfortunate that the file is commited and not
generated during the build process.
|
|
From: Dimitri v. H. <do...@gm...> - 2013-06-04 18:01:21
|
On Jun 3, 2013, at 22:45 , Philipp Moeller <phi...@ge...> wrote: > > NB: To add a config variable you need to add it to the config.xml file > and not to the configoptions.cpp file. Don't forget to rerun > configgen.py. It is really unfortunate that the file is commited and not > generated during the build process. This is limitation of the Windows build. When using ./configure & make on Linux/MacOSX/Cygwin there is a build rule to trigger a regeneration whenever config.xml changes. Regards, Dimitri |
|
From: Philipp M. <phi...@ge...> - 2013-06-06 02:15:27
|
Dimitri van Heesch <do...@gm...> writes: > On Jun 3, 2013, at 22:45 , Philipp Moeller <phi...@ge...> wrote: >> >> NB: To add a config variable you need to add it to the config.xml file >> and not to the configoptions.cpp file. Don't forget to rerun >> configgen.py. It is really unfortunate that the file is commited and not >> generated during the build process. > > This is limitation of the Windows build. When using ./configure & make on > Linux/MacOSX/Cygwin there is a build rule to trigger a regeneration whenever > config.xml changes. This is odd. It is possible to have MSBuild Tasks run an external executable depending on some resource and some platform-independent build tools also support generating that kind of solution file. Maybe its time to switch to CMake? |
|
From: Robert D. <rcd...@gm...> - 2013-06-06 16:34:08
|
+1 to CMake. I'm pretty good with CMake so I'm willing to help produce the build system if there is interest. On Wed, Jun 5, 2013 at 6:46 PM, Philipp Moeller <phi...@ge...> wrote: > Dimitri van Heesch <do...@gm...> writes: > >> On Jun 3, 2013, at 22:45 , Philipp Moeller <phi...@ge...> wrote: >>> >>> NB: To add a config variable you need to add it to the config.xml file >>> and not to the configoptions.cpp file. Don't forget to rerun >>> configgen.py. It is really unfortunate that the file is commited and not >>> generated during the build process. >> >> This is limitation of the Windows build. When using ./configure & make on >> Linux/MacOSX/Cygwin there is a build rule to trigger a regeneration whenever >> config.xml changes. > > This is odd. It is possible to have MSBuild Tasks run an external > executable depending on some resource and some platform-independent > build tools also support generating that kind of solution file. Maybe > its time to switch to CMake? |
|
From: Dimitri v. H. <do...@gm...> - 2013-06-06 17:24:13
|
Hi Robert, On Jun 6, 2013, at 18:33 , Robert Dailey <rcd...@gm...> wrote: > +1 to CMake. I'm pretty good with CMake so I'm willing to help produce > the build system if there is interest. There are quite some custom steps in doxygen's build, but you can migrate the build to CMake I'm interested. > 2013 at 6:46 PM, Philipp Moeller > <phi...@ge...> wrote: >> Dimitri van Heesch <do...@gm...> writes: >> >>> On Jun 3, 2013, at 22:45 , Philipp Moeller <phi...@ge...> wrote: >>>> >>>> NB: To add a config variable you need to add it to the config.xml file >>>> and not to the configoptions.cpp file. Don't forget to rerun >>>> configgen.py. It is really unfortunate that the file is commited and not >>>> generated during the build process. >>> >>> This is limitation of the Windows build. When using ./configure & make on >>> Linux/MacOSX/Cygwin there is a build rule to trigger a regeneration whenever >>> config.xml changes. >> >> This is odd. It is possible to have MSBuild Tasks run an external >> executable depending on some resource and some platform-independent >> build tools also support generating that kind of solution file. Maybe >> its time to switch to CMake? It is not that it is not possible. It just hasn't been implemented. Note that I do almost no development on Windows myself, I only build and test the Windows binaries just before a release, so for me is not much of an issue. Regards, Dimitri |
|
From: Robert D. <rcd...@gm...> - 2013-06-06 20:16:57
|
On Thu, Jun 6, 2013 at 12:24 PM, Dimitri van Heesch <do...@gm...> wrote: > Hi Robert, > > On Jun 6, 2013, at 18:33 , Robert Dailey <rcd...@gm...> wrote: > >> +1 to CMake. I'm pretty good with CMake so I'm willing to help produce >> the build system if there is interest. > > There are quite some custom steps in doxygen's build, but you can migrate the build to CMake > I'm interested. (Sending again to mailing list this time, sorry for the dupe) Ok I'll get started on it tonight. If you don't mind, to help move me along quicker, can you please describe some important points about the build system that need to be carried over? Specifically the code generator, how it needs to run, what source files it generates, etc. Just really anything that comes to mind, no matter how trivial, please list it here so I don't miss it :) Thanks!! |
|
From: Dimitri v. H. <do...@gm...> - 2013-06-06 20:39:46
|
On Jun 6, 2013, at 22:16 , Robert Dailey <rcd...@gm...> wrote: Hi Robert, > On Thu, Jun 6, 2013 at 12:24 PM, Dimitri van Heesch <do...@gm...> wrote: >> Hi Robert, >> >> On Jun 6, 2013, at 18:33 , Robert Dailey <rcd...@gm...> wrote: >> >>> +1 to CMake. I'm pretty good with CMake so I'm willing to help produce >>> the build system if there is interest. >> >> There are quite some custom steps in doxygen's build, but you can migrate the build to CMake >> I'm interested. > > (Sending again to mailing list this time, sorry for the dupe) > > Ok I'll get started on it tonight. > > If you don't mind, to help move me along quicker, can you please > describe some important points about the build system that need to be > carried over? Specifically the code generator, how it needs to run, > what source files it generates, etc. Just really anything that comes > to mind, no matter how trivial, please list it here so I don't miss it > :) Some things to carry over: - options --with-doxywizard, --with-doxyapp, --with-doxysearch --with-sqlite3, --with-libclang, --with-libclang-static - checking for flex, bison, perl & python (required for building), bison has to be version 1.35 or higher - checking for Qt4 (optional needed for --with-doxywizard) - checking for Xapian (optional needed for --with-doxysearch) - checking for Sqlite3 (optional needed for --with-sqlite3) - checking for libclang (optional needed for --with-libclang) (for the current checks and options see the configure script) - linking specific libclang/llvm libraries staticly (optional needed for --with-libclang-static) - I build ce_parse.cpp and ce_parse.h from constexp.y with proper dependency tracking - I create a bunch of .cpp files from .l files (flex), each using their own -p option. - I create *_js.h from a bunch of .js files via a sed command (same for other 'resource' files) - I post-process the the output of flex with a perl filter before writing it to disk - I create configoption.cpp from config.xml via a Python script (most of the 'special stuff' can be found in src/libdoxygen.t and src/libdoxycfg.t, to tmake config files). - a src/settings.h is to be generate with USE_SQLITE3 and USE_LIBCLANG set depending on --with-sqlite3 and --with-libclang - a src/version.cpp should be generated with the version of doxygen (current stored in the configure file, but that could better be another file). Regards, Dimitri |
|
From: Robert D. <rcd...@gm...> - 2013-06-07 00:21:18
|
On Thu, Jun 6, 2013 at 3:39 PM, Dimitri van Heesch <do...@gm...> wrote: > Hi Robert, > > Some things to carry over: > - options --with-doxywizard, --with-doxyapp, --with-doxysearch --with-sqlite3, --with-libclang, --with-libclang-static > - checking for flex, bison, perl & python (required for building), bison has to be version 1.35 or higher > - checking for Qt4 (optional needed for --with-doxywizard) > - checking for Xapian (optional needed for --with-doxysearch) > - checking for Sqlite3 (optional needed for --with-sqlite3) > - checking for libclang (optional needed for --with-libclang) > (for the current checks and options see the configure script) > - linking specific libclang/llvm libraries staticly (optional needed for --with-libclang-static) > - I build ce_parse.cpp and ce_parse.h from constexp.y with proper dependency tracking > - I create a bunch of .cpp files from .l files (flex), each using their own -p option. > - I create *_js.h from a bunch of .js files via a sed command (same for other 'resource' files) > - I post-process the the output of flex with a perl filter before writing it to disk > - I create configoption.cpp from config.xml via a Python script > (most of the 'special stuff' can be found in src/libdoxygen.t and src/libdoxycfg.t, to tmake > config files). > - a src/settings.h is to be generate with USE_SQLITE3 and USE_LIBCLANG set depending > on --with-sqlite3 and --with-libclang > - a src/version.cpp should be generated with the version of doxygen (current stored in the > configure file, but that could better be another file). Concerning third party dependencies that you do not build yourself as part of your make command, would you be able to maintain your own binaries for these in a repository? I already have a CMake framework that I can drop into doxygen and use. To be the most platform agnostic, I have set it up to download archives of precompiled binaries for third party libraries from an FTP/HTTP/Windows file share of your choosing (configurable in CMake cache). Basically for every platform or toolchain you plan to build doxygen on or with, you will need to have include files + binaries in an archive. Those will sit in a repository and the CMake scripts will download them, extract them, and automatically setup include directories and dependencies for you. There are a couple of benefits to having this approach: 1. No need to search for these libraries on the system. The CMake scripts will always be able to guarantee that they are on the system since it will be downloading them from a repository you maintain. 2. Easier for new developers to just pick up the code and start building, since they do not have to spend time building libraries. 3. Windows doesn't have an apt-get (unless you use cygwin, which is just another dependency to worry about) mechanism, so this makes up for that and makes it super easy to get a build started on Windows. The downside, of course, is that this can become a maintenance problem if you have a ton of libraries and/or platforms or toolchains to support. Let me know how you want to approach this, as it will deeply impact the work. Personally I suggest we take this approach, assuming you can setup an FTP/HTTP server somewhere to pull down the archives. I will also post this in the dev mailing list, as I have created a dedicated thread there for CMake discussion. Join me there! |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X