[Boost-build] [BBv2] Dealing with multiple boost-build installations

From: João Abecasis (jpabecasis_at_[hidden])
Date: 2006-04-09 12:09:49

Hi!

I'm trying to package boost-build with another project, trying to keep 
external dependencies minimal and things straightforward for the user. 
In the process I stumbled upon some issues that arise when one attempts 
to share configuration files across Boost.Build installations and would 
like to hear your thoughts.

The path I took to package Boost.Build was to copy tools/build/v2, in 
its entirety to my project and to add a boost-build.jam file pointing to 
it in the root of the project:

     <project-root>/
         build-system/
             <Boost.Build v2>
         boost-build.jam
         project-root.jam
         <other project files and directories>

Pending automatic configuration of compiler toolsets... this setup 
should allow the user to use the provided copy of Boost.Build, to 
override it by setting the BOOST_BUILD_PATH environment variable, and to 
configure it in the usual ways. For most users, things should just work.

The problem is that this setup breaks exactly for those who already use 
boost-build and have configured and tweaked to their tastes. Here's what 
I got when I first tried this out:

     warning: couldn't find BoostBook xsl or dtd directories;
     warning: please set "BOOST_ROOT" variable to the root directory of 
your boost installation. Searched in:
     warning: tools/boostbook
     <project-root>/build-system/../../boostbook
     <project-root>/build-system/build/toolset.jam:26: in toolset.using 
from module toolset
     <project-root>/build-system/build/project.jam:756: in using from 
module site-config
     /etc/site-config.jam:12: in modules.load from module site-config
     <project-root>/build-system/build-system.jam:102: in load from 
module build-system
     <project-root>/build-system/kernel/modules.jam:261: in import from 
module modules
     <project-root>/build-system/kernel/bootstrap.jam:121: in 
boost-build from module
     <project-root>/boost-build.jam:2: in module scope from module

What this means is that the boostbook toolset is configured in 
/etc/site-config.jam, but the toolset can't find additional files it 
needs (they'd be found in a full Boost package). This happens even 
though the project doesn't use anything from the Boost Documentation 
toolchain, or even require anything else from the Boost distribution 
(not for the time being, anyway).

Possible workarounds I can apply to the packaged copy of BB include:

     1) remove config processing altogether
     2) "fix" boostbook (and possibly other) toolset(s) so it doesn't go
        into diagnostics in the configuration step
     3) remove the boostbook (and possibly other) toolset(s), leaving an
        empty init function
     4) add boostbook dependencies to my project (taken to the limit I'd
        be forced to add the full Boost distribution, for quickbook...)

(An empty init function may still be required for removed toolsets, 
because the user might be trying to configure them all the same.)

None of the approaches above really pleases me. Options 1-3 add to my 
workload, reducing the benefits of Boost.Build. And option 4) adds 
unnecessary cruft to my package. Ideally, I'd like to ocasionally update 
Boost.Build from CVS and be done with it. Anyway, I believe the issue is 
more general than the boostbook issue and the discussion will benefit 
other users and packagers.

One part of the problem lies specifically with the BoostBook toolset. 
Should it be issuing diagnostics in the configuration step, before it is 
known if it's ever going to be used? Since it depends on additional 
files, I'll go further and ask, should the BoostBook toolset (or my very 
own quickbook toolset, for that matter...) even be included in the 
Boost.Build tree? Shouldn't it be provided in a separate BoostBook 
package, instead?

Another problem stems from the fact that Boost.Build configuration files 
are actually "executables". They're tied up to a particular installation 
of Boost.Build and they're not meant to be forward/backward compatible 
or friendly. For instance, what happens if the user has

     using my-toolset : <configuration> ;

in his configuration files?

I think, one step in the right direction would be for toolset.using to 
ignore toolsets it can't find. This would be signalled to the user with,

     warning: skipping configuration of unknown toolset my-toolset
     warning: in /etc/site-config.jam: line xxx

Comments?

João