Re: [Boost-build] Boost build failed if custom toolset path is not available

Subject: Re: [Boost-build] Boost build failed if custom toolset path is not available
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-02-25 17:29:58

On 2/25/2016 1:55 PM, Vladimir Prus wrote:
> On 25-Feb-16 7:47 AM, Edward Diener wrote:
>>>
>>>    That's not sufficient.  Boost.Build is specifically
>>> designed to allow building with multiple toolsets
>>> in the same invocation.
>>
>> That does not change my argument, even if building with multiple
>> toolsets in the same invocation. Whatever those
>> multiple toolsets are my argument is that their "using xxx" should be
>> delayed until Boost build determines that the
>> "xxx" is actually being used.
>
> The issue is that it's not always possible to determine that xxx is
> being used without first doing some initialization.
> Consider this, which is already supported:
>
>      using gcc : : /opt/gcc4/bin/g++ ;
>      using gcc : : /opt/gcc5/bin/g++ ;

I did not realize that this was supported. I thought that in "using xxx" 
the xxx had to be totally distinct. I also thought that if you have 
"using xxx" then you must specify the toolset as xxx and not xxx-n.n, 
even if xxx turns out to be version n.n. I did understand that "using 
gcc" can be any version of gcc.

My solution, given how Boost build works as you explain above, is that 
"using xxx" for a compiler toolset would be immediately processed while 
"using xxx-n.n" would be lazily processed ( only processed when 
encountered as a specific toolset during a Boost build invocation).

>
> Given that, you can do:
>
>      b2 toolset=gcc-4.8
>
> and the way it works is that we first ran g++ to determine its version,
> and then you can specify the
> version to use. This approach has some benefits over asking the user to
> explicitly give the version,
> since the manually-specified version can easily become out-of-date.

Sounds reasonable. But if I had "using gcc-5.1" somewhere there's no 
need to process it until I specified "b2 toolset=gcc-5.1".

>
> Another use case, that we don't currently don't support,

I think you meant "Another use case, that we currently don't support,"

> is selecting
> toolset based on other properties.
> For example, if one has:
>
>      using gcc : : /opt/gcc-for-arm/bin/g++ ;
>      using gcc : : /opt/gcc-for-mips/bin/g++ ;
>
> then it would be great to be able to do
>
>      b2 architecture=arm
>
> and have the first toolset invoked. Again, this requires that we do some
> initialization up-front,
> as otherwise we'd have no idea what architecture(s) each gcc handles.
>
> Is there a way to make the above use cases work while also addressing
> your suggestions?

I specified it above. Compiler toolsets without version can be immediate 
but with version is lazy.

In my particular user-config.jam on Windows all compiler toolsets for 
gcc and clang have a version as part of the toolset name.