[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kdoc/doxygen
From:       Peter Putzer <pputzer () edu ! uni-klu ! ac ! at>
Date:       2000-11-26 14:06:33
[Download RAW message or body]

On Mon, 27 Nov 2000, Sirtaj Singh Kang wrote:

> 
> On Sun, 26 Nov 2000, Peter Putzer wrote:
> [snip]
> > As for kdoc's stability and all, around 2.0 it didn't even RUN, though
> > that got fixed a week or so later. Unfortunately 2.0a42 didn't build
> > parameter lists, which kinda defeats the point of a doc-tool.

[snip]
 
> 2. The kdoc parser was too unwieldy to a) parse heavily templated code b)
> keep up with the preprocessor stuff that is appearing in KDE all the time,
> like k_dcop:, "Q_PROPERTY" or "EXPORTDOCKCLASS". I think most people will
> agree with me that just running the preprocessor, even though kdoc has
> supported this for a long time, is not really an option since a lot of
> context information (eg signals) gets lost.
> 
> So over the last few weeks I have totally rewritten the parser in kdoc,
> and through some absolutely godawful regexps it is now quite complete and
> extensible. It does not support everything 100% yet, but is finally able
> to take on new features without making eyes bleed.

I'm not quite convinced that Perl is the optimal language for parsing
context-free languages, but as that's what you've chosen...

> I've also added manpage support, proper (non-Polish!) latex support, and
> the docbook and HTML output will be changed quite heavily once the parser
> is complete, for example the HTML output will properly support stylesheets
> for customization using style classes for various parts of the docs.
> 
> I've also recently discovered that XML schemas exist for describing an OO
> API and adding support for that into kdoc is only a few hundred lines of
> code.

That sound's interesting for post-processing with other tools.

> Other stuff like multiple libdirs (ie hierarchical repositories for .kdoc
> files for kdevelop) have been implemented and removed from the wishlist.
> 
> Expect more in the next few weeks.
> 
> One thing that I will always try to do is make sure it atleast generates
> kdelibs docs properly before I make a commit (kdelibs has always been my
> primary test case), but I cannot fight stuff like EXPORTDOCKCLASS
> appearing without my knowing it.

Yes, that's very important, as generating documentation for kdelibs
probably kdoc's main use. Of course you're not at fault when someone
suddenly adds a new macro for header-directives, but the parser will
hopefully be robust enough spew out at least the basic stuff (parameters,
...) correctly.

cheers,
Peter

[prev in list] [next in list] [prev in thread] [next in thread]