Re: [Boost-build] naive usage of bootstrap.sh

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:
> Stefan,
>
> 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
>>>>> do.
>>>>
>>>> I entirely agree. I originally was very confused as it wasn't clear
>>>> what
>>>> that script's job was, but eventually I just got used to it and
>>>> started
>>>> 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
>>>> itself,
>>>> 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
documenting clearly.

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
>>>> from
>>>> system package "boost-build") would ignore the 'BOOST_BUILD_PATH'
>>>> variable. Perhaps 'bootstrap.sh' causes the bjam / b2 executable to
>>>> have
>>>> 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
>> with.)
>
> 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.

Thanks,
        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...