Re: [Doxygen-users] Adding Custom Commands to execute Shell Scripts

[Rosen D. <ros...@gm...>]

hi adam,

Thanks for the feedback. Here is our current documentation:

http://openrave.programmingvision.com/ordocs/english/html/index.html

As you can see, it needs a lot of work to make it something like
(http://matplotlib.sourceforge.net/gallery.html).

I think the simplest and fastest way for me would be just add the
feature in the C++ code and send a patch.

Because i want things done correctly, the INPUT_FILTER is very
difficult for many reasons; i would have to create a parser for a
subset of doxygen. If it was just a matter of simply replacing
$OUTPUT_GOES_HERE, then ALIASES would be more than enough.

As for the rest of your comments:

- Although we provide all scripts, we have no interest in users being
able to build their own documentation.

- we use cmake, not autotools

- we want all information/example code pertaining to a particular
module in one location, the source file.

- Let me worry about \shell commands being scattered throughout our project ;0)

- ALIASES can always be used to wrap the \shell commands.

rosen,

2010/7/18 Adam Nielsen <a.n...@sh...>:
>>> Couldn't you use INPUT_FILTER to write a parser that runs these \shell
>>> commands instead?
>>
>> that means we would need to run a lexer and figure out the comments,
>> and then parse the language tags. do you know of such a script? a
>> \shell tag is so much easier and natural.
>
> Depends how flexible you need it to be.  Unless you want to run hundreds of
> different shell commands you could just replace it with some generic tokens
> like $OUTPUT_GOES_HERE and then use sed or something in INPUT_FILTER to do a
> search and replace with the output of some predefined commands.  The advantage
> there being if you change one of the programs that generates the output, you
> only need to update your INPUT_FILTER script rather than hundreds of \shell
> commands scattered throughout the docs/code.
>
>> i'm not sure why we are talking about 'platform independent'
>> documentation generation when clearly doxygen is filled with many
>> interesting features that execute shell commands at a user's demand,
>> like the INPUT_FILTER configuration.
>
> Executing shell commands isn't a problem, but shell scripts usually run
> external programs and these can be configured differently on different
> systems.  That's why autoconf and other build environments have tests to make
> sure programs exist, are the correct versions, etc.  I would imagine that in
> an ideal world INPUT_FILTER would call a local script which has been generated
> as part of the configure process.
>
>> anyway, the information we put in
>> our doxygen comments and how we generate the actual documentation
>> heavily depends on our environment, even though our project is
>> platform independent...
>
> Hope your documentation generation procedure is well documented then ;-)
>
>> as my original email said, all doxygen has to do is pass the "progname
>> args" to the portable_system function.
>
> Well if it's that simple I'm sure a patch would be cheerfully accepted :-)
>
> Cheers,
> Adam.
>