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

From: João Abecasis (jpabecasis_at_[hidden])
Date: 2006-04-21 12:14:10

David Abrahams wrote:
> João Abecasis <jpabecasis_at_[hidden]> writes:
> 
>> 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, 
> 
> Bad idea.  Why would anyone override the path to Boost.Build?

For instance, to avoid the issue I reported below. Namely that the 
user-config.jam and site-config.jam configuration files attempt to 
configure toolsets that may not be available in the copy of Boost.Build 
provided with my project.

>> and to configure it in the usual ways.
> 
> The usual ways to configure BB is to edit user-config.jam and
> site-config.jam, **outside** the BB tree.  Why would anyone need to
> point at a different BB installation in order to do that?

They don't need to point at a different installation of BB just to get 
at the configuration files. That should work out of the box, because I 
provide a *copy* of Boost.Build with the package. There are still valid 
reasons to point at another version of BB though, e.g., if a newer 
version is available or if one has a customized toolset/BB.

The point I tried to make further down in the post was that currently, 
the configuration is too tied up to a single installed version of BB and 
that some changes could make the system more permissive and perhaps 
user-friendly.

>> 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). 
> 
> So /etc/site-config.jam was wrong and needs to be fixed.

In this particular case, perhaps you are right, in the sense that this 
error message could be avoided. I could have the BoostBook directories 
set in site-config, together with the DocBook directories that are there 
already. Still, in this case, I choose to leave it blank so I can 
experiment with different versions of the "Boost documentation 
toolchain" at will.

Still, my question remains, should the BoostBook toolset complain before 
it knows if the user wants to use it? Could the warnings or error 
messages be deferred to the point where boostbook is actually invoked?

> I guess I don't understand the problem...

I hope I managed to make it clearer, if not... well, ask away :-)

Thanks for your comments!

João