Boost logo

Boost-Build :

Subject: Re: [Boost-build] naive usage of
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 to build some
>>>>> boost tools not include things like --show-libraries , without-icu
>>>>> etc. I'm now totally confused as to what 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 "" 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 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 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 `./ <options> && ./b2` and
`./ && ./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
"" 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
would have any business with configuring, too.

>> I think it would also help if 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 '' 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, 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
>> 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.


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

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