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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk