Re: [Boost-build] switching on toolset

Subject: Re: [Boost-build] switching on toolset
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2015-06-22 14:30:39

On 6/22/2015 6:25 PM, Robert Ramey wrote:

Robert,
> c) Its totally unclear what happens if there is a conflict between the switches used on the command line and the
> switches automatically added in by the jamfile.  Which would take precedence? would this internal logic drop
> switches I've specifically requested?.  Would it add switches I don't know about?  What would it do?  How would
> I find this out?
>
> d) what happens when I invoke b2 for the whole of boost with some set of switches. Now would some libraries get
> built with one set of switches and other libraries get built with a different set?  How would I know what's
> getting built with what?  Suppose one library uses another library, how do we know that there won't be any
> incompatibilities?  If there are any, and they show up later in the process when I try to use the libraries, How
> will we track down the source?  And how will we fix the problem?

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.

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? What are example of cases where you'd suggest
it be employed - like, which libraries and which properties?

- Volodya