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-24 16:57:19

On 2/24/2016 3:39 PM, Steven Watanabe wrote:
> AMDG
>
> 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 ?
>>
>
> Yes.
>
> - 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.