Subject: Re: [Boost-build] naive usage of bootstrap.sh
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2016-10-24 16:51:43
On 24.10.2016 15:19, Vladimir Prus wrote:
> On 24-Oct-16 6:31 PM, Stefan Seefeld wrote:
>> On 24.10.2016 10:56, Vladimir Prus wrote:
>>> On 24-Oct-16 5:40 PM, Stefan Seefeld wrote:
>>>> On 23.10.2016 15:55, Robert Ramey wrote:
>>>>> Which looks quite wrong to me. I expect bootstrap.sh to build some
>>>>> boost tools not include things like --show-libraries , without-icu
>>>>> etc. I'm now totally confused as to what bootstrap.sh is supposed to
>>>> I entirely agree. I originally was very confused as it wasn't clear
>>>> that script's job was, but eventually I just got used to it and
>>>> ignoring it.
>>>> However, I still think this is wrong, and I entirely agree with Robert
>>>> that "bootstrap.sh" should do nothing but prepare the build tool
>>>> so all the build-specific parameters should then be added to the
>>>> invocation of 'bjam' (or 'b2' or whatever the name of the day is).
>>> The current behaviour is not quite arbitrary either - it was originally
>>> made to help people who like to pass some values to configure script,
>>> and make those values stick. It may be easier to skip that and just
>>> instruct to read project-config.jam and modify to taste, but I'm sure
>>> others will complain just as loudly :-(
>> At the very least I think bootstrap.sh should not accept options such as
>> --with... or --without...
> Why? Again, maybe nobody cares any longer, but I think it was requested
> by some folks some time ago? Could you suggest a criteria which options
> should be accepted and which not?
> If bootstrap.sh is made to accept no options, to to pass all options
> to b2, then we'd have too add an option to b2 to save the passed options
> for future use.
So you are saying that `./bootstrap.sh <options> && ./b2` and
`./bootstrap.sh && ./b2 <options>` are strictly equivalent (modulo the
fact that the latter won't save the options) ? I think that's worth
Other than that, I think it's a matter of separating concerns: the
"bootstrap.sh" script is concerned with generating (compiling) the build
tool for the given platform, while "b2" invokes the build. Configuring
the the build is (in my mind at least) a concern of the build tool,
rather than the tool that builds the build tool. Coming from the
autotools world with its separation of "configure" and "make" I can see
the appeal of separating the two, but given that it's b2's job to do
some configure checks, I simply found it confusing that bootstrap.sh
would have any business with configuring, too.
>> I think it would also help if bootstrap.sh would print out a message
>> explaining that it generated project-config.jam, in addition to bjam/b2.
> Yes, it can be added.
>>>> Perhaps relatedly: I noticed on my laptop that `bjam` (as installed
>>>> system package "boost-build") would ignore the 'BOOST_BUILD_PATH'
>>>> variable. Perhaps 'bootstrap.sh' causes the bjam / b2 executable to
>>>> certain values hard-coded / compiled in, and that such command-line
>>>> options as '--prefix' will thus affect which values that are ?
>>>> That ought to be documented, at the very least !
>>> No, bootstrap.sh does not hardcode any values; it only sets up
>>> project-config.jam. If you system boost-build package does not work,
>>> it's veyr likely because it's some very old version.
>> `bjam -v` reports "Boost.Jam Version 2015.07. OS=LINUX.", and was
>> installed pas part of the boost-jam-1.60.0-7.fc24.x86_64 package, thus
>> is actually fairly recent. (I had some local modifications to
>> boost.build that I wanted to try out, but wan't able to point bjam at my
>> version of Boost.Build; it insisted on using the one it was installed
> That is strange; does running with --debug-configuration report
> anything? BOOST_BUILD_PATH, if it's actually set in environment,
> is searched before anything else.
I will try when I get a chance.
-- ...ich hab' noch einen Koffer in Berlin...
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk