Re: [Boost-build] Improving 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 
release'.

   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ć