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 23:47:44

On 2/24/2016 8:23 PM, Steven Watanabe wrote:
> AMDG
>
> On 02/24/2016 05:05 PM, Edward Diener wrote:
>> On 2/24/2016 5:45 PM, Steven Watanabe wrote:
>>>
>>> On 02/24/2016 02:57 PM, Edward Diener wrote:
>>>>
>>>>   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.
>>>
>>>     This particular problem can (and should) be
>>> solved by prefixing the gcc command with
>>> a command to set the path.  Unfortunately you
>>> can't solve this manually with:
>>>
>>> using gcc : : set "PATH=C:\\MinGW\\bin;%PATH%" && C:/MinGW/bin/g++ ;
>>>
>>> because the && gets quoted.
>>
>> There are other ways to solve this problem ( command as a batch file
>> which eventually invokes g++ or multiple user-config.jams with the
>> correct one being set for any particular toolset ),
>
>    Neither of which is suitable for implementation
> within Boost.Build.
>
>> but the entire point
>> is that none of this should be needed if the "using xxx" were delayed
>> until a toolset was specified ( or defaulted ).
>>
>
>    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.

>  Note also that this is a
> solved problem.  msvc already has to call vcvarsXXX.bat
> before running cl.  The fix here is essentially similar.
>

I do not agree that this is a solved problem, unless you inherently put 
in logic in Boost build that knows about each gcc/mingw(-64) and/or 
clang combination, as Boost build knows about the far fewer variations 
of vc++.

>>
>> Do you mean to say that you wouldn't know whether or not to use xsltproc
>> during a b2 invocation until you process a "using xsltproc" statement ?
>>
>
>    Yes.  Unless we run xsltproc.init, any
> Jamfiles that use xsltproc will most likely
> error out without Boost.Build ever realizing
> that there is such a thing as xsltproc.
>
>> <snip>
>> But you never are going to use gcc unless the b2 invocation specifically
>> tells you to use it or you are searching for a default compiler to use.
>
> Or if gcc is hard-coded in a Jamfile.
>
>> In either case why could not processing of any "using gcc" statements be
>> put off until you encounter either situation. Clearly in cases where the
>> end-user is specifying a toolset that is not gcc something there would
>> be no need to process a "using gcc" statement.
>>
>
>    In order to make such a determination we have
> to know what using gcc means, and all information
> about the meaning of using gcc is encoded inside
> gcc.init.
>
>> My objection to the way that Boost build currently works is that I can
>> be passing a b2 command line like:
>>
>> b2 toolset=msvc-12.0 ...etc.
>>
>> and Boost build will still be processing a large list of "using xxx"
>> statements in my user-config.jam which are completely irrelevant to my
>> Boost build invocation, and stopping the invocation if any of these
>> irrelevant "using xxx" statements fail.
>>
>
>    The way Boost.Build is organized, it's impossible
> to determine whether they are irrelevant without
> processing them.
>
> Example:
>
> using quickbook ;
> xml random : random.qbk ;
>
> This meaning of this Jamfile in English is roughly:
> a) Initialize quickbook
> b) Take my .qbk file and convert it to an .xml file somehow.
>
>    This works because quickbook defines a rule that
> says how to convert a .qbk file to an .xml file.
> As an absolute minimum, we have to run
> generators.register [ new quickbook-binary-generator
> quickbook.quickbook-to-boostbook : QUICKBOOK : XML ] ;
> when we see using quickbook.  Otherwise, there
> is no way to know that .qbk -> .xml has anything
> to do with quickbook.
>    Actually, it looks like someone (probably me) made
> quickbook lazy a long time ago.  I see quickbook.init
> does almost nothing, except to save the executable path.
> The same goes for xsltproc, so it's clear that this
> is possible for these simple tools.  Again, I'm not
> saying that your suggestion is wrong, is just that:
> - Some initialization must be done immediately.  It
>    can't all be put off till later.
> - It's going to be a lot of work to apply it to
>    complex tools like the C++ toolsets and validate
>    that it doesn't cause any nasty surprises.

OK, what can I say. You know my arguments and I understand it will be 
much more work than I thought it would be to process toolsets lazily.