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: Steven Watanabe (watanabesj_at_[hidden])
Date: 2016-02-24 20:23:05

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.  Note also that this is a
solved problem.  msvc already has to call vcvarsXXX.bat
before running cl.  The fix here is essentially similar.

>
> 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.

In Christ,
Steven Watanabe