Subject: Re: [Boost-build] Boost build failed if custom toolset path is not available
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-02-24 16:57:19
On 2/24/2016 3:39 PM, Steven Watanabe wrote:
> On 02/24/2016 01:01 PM, Edward Diener wrote:
>> The larger issue, which I have made in the past on this mailing list, is
>> that Boost build "executes" a "using xxx" even when the xxx toolset is
>> not being used in any way. If it waited until toolset xxx was actually
>> being used before "executing" a "using xxx" Boost build would be much
>> faster and much simpler to use for the end-user. Is it really too much
>> work to make this change in the Boost build logic ?
> - Delaying the actual configuration to some
> unspecified point will make any problems
> that much harder to debug. As things stand,
> at least anyone can figure out why it's
> failing: user-config.jam runs exactly what
> you tell it to.
Granted, but I do not think you realize how hard it is for the actual
end-user of Boost build to debug anything now given the complexity of
how Boost build decides anything, so the change will hardly affect
anyone but Boost build developers and experts.
> - The implementation of laziness needs to
> be handled separately by each toolset, as
> we still need to do enough initialization
> to determine when a toolset is "used"
Why does running the "using xxx" command determine when a toolset is
used ? I would think that an actual specification of a toolset in a b2
command line determines when a toolset is used.
> - Instead of having two states, initialized
> or not initialized, each toolset would have
> three states: ready to use, initialized but
> not fully configured, and not initialized.
> This increase in complexity is likely to
> propagate everywhere, possibly even into
> user Jamfiles.
Could you not just cache "using xxx" statements in memory and then when
it is determined that the "xxx" toolset is being used, invoke the "using
xxx" command line which you presently invoke when Boost build sees a
"using xxx", remove the "using xxx" from the cache, and then do whatever
else using a toolset involves for its particular case.
> With that being said, this change is on my
> long-term todo list, but it's a fairly major
> project and is unlikely to happen in the
> immediate future.
OK, thanks !
From this end-user's point of view, where various versions of
gcc/mingw(-64) on Windows and clang on Windows ( which depends on
mingw(-64)/gcc ) are mutually exclusive as far as needing that
particular version first on the Windows PATH, it would be a great
improvement if "using xxx" were not executed until xxx is actually being
used. The internal manipulations I have to do in order to run multiple
versions of gcc and/or clang on Windows for Boost build is ridiculous
and would be totally unnecessary if Boost build just didn't have to
execute every "using xxx" it sees in my user-config.jam when I am just
using a single version of gcc or clang in my b2 command line.
It would also speed up the execution of Boost build as "using xxx"
statements in places like user-config.jam would never get invoked the
vast majority of times when running b2 against jam files. I am not
talking of only compiler toolsets here but of many other toolsets in a
user-config.jam such as xsltproc, boostbook, doxygen, fop, quickbook,
auto-index, python, and whatever else, most of which will never be used
during a single invocation of Boost build using the b2 command line.
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