There are "clean" and "realclean" targets, but they may
only be visible from the abi/src level, not the abi/ level.
I'm not quite sure why our settled this way, but doing
your builds from the abi/src/ level will build the
entire tree (read: you won't be missing anything) and
will be nominally faster.
> MSWordView uses oledecod, which was written by Arturo Tena, and was
> the basis for his cole library, which just extended oledecod and
> added olecod. I haven't explored them much, but they appear to just
> extract streams from an OLE2 file. I'll take a look at how MSWordView
> handles the streams in it's conversion process, and see if I can
> replace the importer and write an exporter. Word 6.0/95/97/98 files
> are all stored as OLE2 objects, and hopefully they don't vary too
> much, so we can support all of them easily.
Aah, thanks for refreshing my memory. It has been a while
since I've checked up on MSWordView or the OLE library
underneath. As you said, decoding OLE streams is just
the precursor to reading a Word-formatted file; the second
is a much more laborious task. We have the very beginnings
of parsing out the file in the tree, but I'm not expecting
that we continue that code base if we have a much cleaner
way to (1) parse the OLE2 file, and (2) serialize the
Word formatting and content into our internal document
structure.
-- Shaw Terwilliger