Boost logo

Boost :

From: Matthew Herrmann (matthew.herrmann_at_[hidden])
Date: 2007-05-15 19:59:37

> Date: Tue, 15 May 2007 19:15:41 +0100
> From: "John Maddock" <john_at_[hidden]>
> Subject: [boost] Improving Boost Build?
> 2) Better docs. Yes, I know it's been said before, but we really must get
> the existing toolsets and their options documented. This need not take too
> long if someone would step up and volunteer to do it.

I would like to add my vote to continuing the active maintenance of
Boost Build V2. I've only ever used V2, and found it to have the best
syntax for expressing hierarchies of libraries out of any of the tools I
reviewed. The fact that there is no middle-man is a great guarantee that
you will never get an unexpected interaction between this and makefiles,
where both sides blame each other.

Better Docs:
The biggest documentation hole for me is in the programming "primitives"
of boost build. To put it in perspective of a language, there are
descriptions of some commonly used functions (exe, lib, alias) and some
common arguments to those functions. But there is no description of what
valid types there are, or what a function _is_. How does the
"<variant>debug" trick work? Is it a map entry, or a single-element
dictionary? How, precisely, does adding a new type of variant work? Is
there language magic, or is the rule referring to a global variable? How
do I make a list of things? How do I take the first one? How do I make a
rule call another rule? How does module import work? Can you import a
module twice? How do exceptions work?

If these areas were better documented, a lot of people (including
myself) would be able to "teach themselves to fish", and hopefully
submit well-written patches to do things like add timeouts to unit test
invocation. I can do the big stuff with bjam, like massively nested
library builds, but just trying to pass an argument to a rule was an
huge and ultimately fruitless exercise.

Matthew Herrmann

Boost list run by bdawes at, gregod at, cpdaniel at, john at