Boost logo

Boost-Build :

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


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:

             <Boost.Build v2>
         <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/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



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