[LLVMdev] [RFC] Moving to Sphinx for LLVM and friends documentation (with partial implementation (in both 10pt and 12pt font)).

David A. Greene greened at obbligato.org
Wed Aug 18 15:55:58 PDT 2010

OvermindDL1 <overminddl1 at gmail.com> writes:

>> It would be a great contribution if someone could port the
>> BoostBook/QuickBook build to make and completely divorce it from Boost
>> proper.  It's a tool a lot of projects could really use, IMHO.
> QuickBook itself uses Boost.Spirit as the parser and the regex engine
> inside Boost, to separate that from Boost 'would' be difficult, except
> there exists a nice little Boost tool call "bcp".  What bcp can do is

I actually meant "Boost.Build" here.  Sorry for creating the confusion.
QuickBook using Spirit is fine.

>> I finally got around to trying this out on my windows machine. The
>> problem is that you have to have a full boost installation so that you
>> can compile quickbook and boostbook as there are no packaged binaries.
>> There are also 3 other packages you have to install.
> You need to compile quickbook, but as stated above that could easily
> be put into LLVM itself so there are no dependencies to download with
> regards to Boost.  boostbook is not something you compile, but rather
> the look and feel infrastructure for the xsltproc compiler (the only
> dependency you would need to get, basically docbook), and you would
> just copy that into the LLVM tree and edit it to suit to taste.  The
> only other dependency you would have is if you want to build pdf's.

I really don't want to see us copying external project code into LLVM.
That becomes a nightmare.  Relying on a packaged version of
Quickbook/Boostbook is fine, as long as such a package is available, but
at the moment, it isn't.

I wasn't advocating that we _must_ build Boostbook/Quickbook as part of
LLVM, only that developers should be able to easily rebuild the
documentation tools if necessary.  Those tools should live separately
from LLVM.  Putting Boostbook/Quickbook in the Boost tree is what
gave us the mess it's in now.  We shouldn't make that mistake again.


More information about the llvm-dev mailing list