Re: [Boost-build] switching on toolset

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