Dirk Reiners wrote:
> Hi All,
[ snip ]
> On Tue, 2006-08-29 at 13:06 +0200, jan p. springer wrote:
>> one possible solution is to split into several doxygen runs. for
>> avango the
>> (outdated) result is here:
>>
>> http://www.avango.org/documentation/doxygen/index.html
>>
>> we defined dependencies for plugins to system libs and have make the
>> parallelization for us, eg.
> ...
>
> OK, that's an idea. I assume you're using tag files and doxygen's
> external documentation option?
yes, extensively.
> One thing that you definitely lose (which
> may or may not be a bad thing for a large system) is the completeness of
> the Inheritance diagram (e.g. fpFieldContainer), not sure what else you
> lose.
yes. you only get inherited classes from the same run. but i think in
current versions (ie. newer than the link above) we enabled searching
the whole thing, regardless of container/include/source distinction.
that may accomodate this shortcoming.
> But in general that's an interesting idea. We could probably create the
> dependencies from the build system automatically (I hate stuff that
> needs manual updates).
>
>> we also distinguish between container doc (what an application writer
>> needs
>> to know, eg. fields), inclusion doc (what someone needs to know when
>> extending
>> classes, eg. virtual, access rights), and source doc (ie. everything).
>
> We have some of that in OpenSG, but the differences seemed to be very
> minimal, so we haven't been using it very actively. How much difference
> did that make for you, how useful is it?
[ snip ]
it gives you a basic idea what the container is like and what fields are
in there. actually the header would look like this:
/**
* \container_doc
*
* \brief some text
* verbose blah
* \end_container_doc
*
* \interface_doc
* \brief some text
* \end_interface_doc
*/
class fpNewContainer : public fpGroup {
public:
fpGLQueryGroup();
virtual ~fpGLQueryGroup();
/**
* \name Fields
*/
//@{
fpSFUInt UIntField; ///< some value (default: 0)
fpSFBool BoolField; ///< some flag (default: true)
//@}
};
so in the container doc you only get \container_doc content and the fields.
we arbitrarily chose ///< as a one-line comment for that. in the include_doc
we add protected and public methods, so people extending containers know
what they can play with.
once we had the thing in place there were some cases that internal code
reshuffeling worked better with the source_doc at hand (but nothing some
unix command line stuff couldn't also accomplish).
that stuff was just for pointing out how this could be done. avango does not
really feature a good documentation nor do we have the time and manpower to
document even the interesting bits (let's say it grew in a very heterogenous
kind of way :) so, what we achieved though with the above was to be able
to extract the (to us) right amount of information at different levels. if
that actually helps any newbie ...
j.
--
+------------------------------------+--------------------------------------+
| jan p. springer | [EMAIL PROTECTED] |
| computer science, buw.media.vrsys | [EMAIL PROTECTED] |
+------------------------------------+--------------------------------------+
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
