> With Jeff Garland's Doxygen XML test data, I've started to build a Doxygen
> XML->BoostBook translator.
Sweet!
>...detail snipped...
> Don't think everything will work yet, of course. Doxygen's XML output omits a
> great deal of structural information that is essential in BoostBook (and in
> C++).
Aside from the example below can you make a list? Perhaps we can influence
the Doxygen XML format.
> For instance, a class might be given the compound name
> "boost::date_time::date". However, Doxygen won't tell us whether this is:
>
> namespace boost { namespace date_time { class date; } }
> or
> namespace boost { class date_time { class date; }; }
> or
> class boost { class date_time { class date; }; };
>
> In all cases, the three entities in this will be <compoundref> elements and
> will be peers. We need to traverse "innerclass" and "innernamespace"
> references to rebuild the structure so that we get the properly nested
> elements:
>
> <namespace name="boost">
> <namespace name="date_time">
> <class name="date">
> <!-- ... -->
> </class>
> </namespace>
> </namespace>
>
> (Interestingly, this was one of the complains about Doxygen's output: that it
> puts nested classes at the same level as their logical enclosing classes)
That's ugly...
> The situation is worse for files: they only tell you what namespaces are used
> in the file, not what other entities are in the file. For classes, structs,
> and unions, we have a way out with the <includes> element, which tells us
> what header file to include to get that entity (we can compare the header
> name against the header file for which we're generating BoostBook).
> Unfortunately, namespace-level typedefs, functions, and enumerations don't
> have the <includes> element, so I'll need to find a better way.
Hmm, that's not good. And yes, the <includes> gives you the data you want
for classes.
> I'd rather not post the resulting HTML until I get a little further. If you'd
> like to try it out, you'll want Doxygen 1.2.18: 1.2.17 generates bad XML as
> does 1.3-rc2 and the current CVS.
At some point we really should feed back our results to the Doxygen development
group. Maybe we can get them to fix the XML output and make it a bit more
friendly for boost-book conversion. Of course I'll help when we get a bit
further...
Also, after studying this in detail have you had any more thoughts about
things that might be missing from boost-book? As I said before, I think
the wrapping the loose <para> tags in a description tag something like
the <detaileddescription> would be a useful addition just to clearly
delineate what these elements represent. And I've been assuming that
given boost-book goals we aren't really interested in things like
<inheritancegraph>, <collaborationgraph>, <incdepgraph>
(include dependency graph), and <programlisting>.
Jeff
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Boost-docs mailing list
[EMAIL PROTECTED]
Unsubscribe and other administrative requests:
https://lists.sourceforge.net/lists/listinfo/boost-docs
