Re: [Boost-build] Rene's 44166 revision commit & toolset version requirements

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2008-04-12 13:45:43

Rene Rivera wrote:
> Note, only darwin.jam uses the feature currently. It simple allows one 
> to have in user-config.jam:
> 
> ====
> using darwin : 4.0.1 ;
> using darwin : 4.0.1~iphone
>   : /usr/local/xyz/bin/arm-apple-darwin-g++
>   : <archiver>/usr/local/xyz/bin/arm-apple-darwin-libtool <striper>
>   : <architecture>arm <target-os>iphone ;
> ====
> 
> And when one asks to build say:
> 
>    bjam toolset=darwin architecture=arm target-os=iphone
> 
> It uses the darwin-4.0.1~iphone to build instead of the default. And 
> *only* in the situation when the <architecture>arm <target-os>iphone 
> requirements are met for the build request.

This sounds smart, and I tried to get this working for gcc too.

Unfortunately I found a bug in
http://svn.boost.org/trac/boost/changeset/44166

The syntax:

        toolset.add-requirements $(r:J=,):$(subcondition:J=/) ;

For conditional requirements (the / ) is unsupported.

E.g. you cannot specify
<toolset>gcc,<target-os>windows:<toolset-gcc:version>3.4.5/<toolset-gcc:flavor>mingw

You need to add two conditionals:
<toolset>gcc,<target-os>windows:<toolset-gcc:version>3.4.5
<toolset>gcc,<target-os>windows:<toolset-gcc:flavor>mingw

I discovered this because the mingw compiler choked on it because
there is already another subfeature, the flavor present. (Details
omitted.)

Fortunately this is easy enough to cure:

if ($requirement) {
        local r = <toolset>$(toolset) $(requirement) ;
        for s in $(subcondition) {
                toolset.add-requirements $(r:J=,):$(s) ;
        }
}

This will do the trick.

Rene, while your idea ( not requiring a separate generator for every
additional set of requirements) is nice at first glance it has a serious
shortcoming:

If the toolset is invoked with a requirement whose condition cannot
be met, the generator tries to compile with an empty value for
$(CONFIG_COMMAND).

Typically the invoked command starts with just the options instead of
the compiler executable.

And this is not only _very_ ugly since it spills out lot of garbage.
Also this might be harmful if the first option happens to be a valid
command to the operating system. (And it confuses the user.)

Any ideas? Possibly $(CONFIG_COMMAND) should have a save default
that echoes an error message and returns with result!=0?
But how to do this in platform independent manner?

Roland

-- 
_________________________________________
  _  _  | Roland Schwarz
 |_)(_  | aka. speedsnail
 | \__) | mailto:roland.schwarz_at_[hidden]
________| http://www.blackspace.at