Boost logo

Boost-Build :

Subject: Re: [Boost-build] switching on toolset
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-06-22 14:56:05

On 6/22/15 11:30 AM, Vladimir Prus wrote:

> Are these points really different from other build systems. Say, people
> trying to use CMake with Boost routinely
> report its failure to detect Boost - in which case obscure message is
> produced, and there's no useful log to
> review, and no debug options, so one has to add echo statements in
> source code to see what's happening.

LOL - I have similar complaints about all build systems.

> In Boost.Build, you can use --debug-building to see options used for
> each metatarget and how they are changing.
>> What I suggest is that if there is some sort of requirements related
>> to the selection of toolset
>> options/features/attributes which cannot be supported, the the bjam
>> code just detect them and bail with an error
>> message which tells the user what he did wrong and maybe how to fix
>> it. This avoids the problems above.

> so you suggest a mechanism to report that properties requested from a
> library are wrong? I think such mechanism exists already, like so:
> rule check-properties ( properties * )
> {
> if <architecture>tape-recorder in $(properties) {
> errors.error "That's total nonsense, sorry" ;
> }
> if <architecture>hand-calculator in $(properties) {
> ECHO "Can't build for hand calculators yet" ;
> return <build>no ;
> }
> }
> lib whatever : whatever.cpp : <conditional>@check-properties ;
> There are even two things one can do - issue an hard error, or skip a
> build of some targets, but not stop entire
> build.

> Are you proposing this mechanism is more widely used?

basically yes.

What are
> example of cases where you'd suggest
> it be employed - like, which libraries and which properties?

I can't speak to that without actually going in and starting for fix
stuff. But let me state the following as a guiding principle that those
who make bjam build scripts should follow:

"The script should execute the build in accordance with what a user can
reasonably expect. If that cannot be done, or there is some conflict so
that the user's expectation cannot be discerned, the script should fail
with an error message suggesting a course of action. It should not make
some guess or unobvious assumption in order to "just work"."

BTW - don't think I'm singling out boost build. I have this complaint
about many software systems - have you ever spent half a day trying to
figure out how to make your system do something only to find it's the
result of some "setting" a few levels deep somewhere? It's the same
problem. How about when you're debugging someone else's code and find
that the operation of some function a few layers deep is affected buy
some setting - or ever worse - history. It's the curse of modern
software development.

Robert Ramey

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