Date: Tue, 15 May 2007 19:15:41 +0100 From: "John Maddock" <john@johnmaddock.co.uk> 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. Regards, Matthew Herrmann