Boost logo

Boost-Build :

From: Jurko Gospodnetić (jurko_for_boost_at_[hidden])
Date: 2007-05-17 18:11:46

   Hi Dean.

> If that's what needs to be done, then I guess someone's gotta do it
> too... We'll see, if there's enough encouragement and support from the
> (or a) community to keep this alive [CAN PEOPLE PLEASE CHIME IN NOW?!]
> then maybe it just might be worth the effort.

   Here's a CHIME for ya... :-)))

   We use Boost.Build in our projects and would definitely not like to
see it abandoned. We are not afraid to get a little dirty to use the
tool and so far we've managed to get it to do almost everything we
wanted but a bit better documentation would definitely be a plus. Some
information you can find only by running into it in old news archives,
having someone tell you or by stumbling onto it in the source code.

   Our main test project automated using Boost.Build consists of a
static library, 2 DLLs, about 5 different utilities linked to those
libraries in different ways, some of the built products linking to
external libraries like wxWidgets, Boost.Build automating external tools
like wxFormBuilder for generating wxWidgets GUI code with most of the
products buildable in two modes - client and admin (compile-time
choice)... It uses our own customized msvc toolset (tried extending the
msvc toolset - but did not work as we wanted so we cloned it for now and
will try to extend msvc again at a later time)... And so far everything
works. :-)

   Some problems we still have open are:

     1. Is there an easy way to see a response file used for a failed
build action? The best workaround we found so far is temporarily denying
  ourselves the right to delete files from the target folder and so
preventing Boost.Build to remove the file. :-)))

     2. We'd like the clean rule to remove all the created and now empty
target folders.

     3. Is there a way to allow a project to to build only with a
specific feature value and have its build ignored in case a different
feature is requested? E.g. if you have three subprojects: A, B & C, of
which A & B are buildable in both debug and release mode while C can
only be built in release mode. Then you'd like 'bjam' or 'bjam debug' to
build projects A & B in debug mode, 'bjam release' to build all three
projects in release mode and 'bjam debug release' to build projects A &
B in both debug and release mode and project C only in release mode.
Simply specifying <variant>release as a requirement for project C has
different semantics and does not work at all in cases like 'bjam debug

   Hope this is taken as 'interest'. :-) Even though we currently do not
have the resources to continue actively researching/developing boost
build. :-( But... we can always hope...

   Best regards,
     Jurko Gospodnetić

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at