Boost build failed if custom toolset path is not available

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Boost build failed if custom toolset path is not available

marfro
Hi,

I am successfully compiling the boost library (1_46_0) for msvc and for gcc.

For gcc I use a custom toolset path. Therefore I created an entry in the user-config.jam file. If that path is not available the whole boost build files even when I build it only for msvc.

After enabling the debug information I see that the build process initializes and checks all using statements of the user-config.jam file. Why is that necessary, since I already named the toolset on the bjam call?

Does anybody know if I can avoid this behaviour so the build still be successfull even though the path is missing?

Best regards,

MF

Reply | Threaded
Open this post in threaded view
|

Re: Boost build failed if custom toolset path is not available

Steven Watanabe-4
AMDG

On 02/17/2016 12:49 AM, marfro wrote:

>
> I am successfully compiling the boost library (1_46_0) for msvc and for gcc.
>
> For gcc I use a custom toolset path. Therefore I created an entry in the
> user-config.jam file. If that path is not available the whole boost build
> files even when I build it only for msvc.
>
> After enabling the debug information I see that the build process
> initializes and checks all using statements of the user-config.jam file. Why
> is that necessary, since I already named the toolset on the bjam call?
>
> Does anybody know if I can avoid this behaviour so the build still be
> successfull even though the path is missing?
>

  It used to be that this was required to work,
and it still does with some tools, just not gcc.
The easiest workaround is to check whether the
path exists:

import path ;
if [ path.exists /path/to/g++ ]
{
    using gcc : /path/to/g++ ;
}

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Boost build failed if custom toolset path is not available

Edward Diener-3
On 2/23/2016 9:35 PM, Steven Watanabe wrote:

> AMDG
>
> On 02/17/2016 12:49 AM, marfro wrote:
>>
>> I am successfully compiling the boost library (1_46_0) for msvc and for gcc.
>>
>> For gcc I use a custom toolset path. Therefore I created an entry in the
>> user-config.jam file. If that path is not available the whole boost build
>> files even when I build it only for msvc.
>>
>> After enabling the debug information I see that the build process
>> initializes and checks all using statements of the user-config.jam file. Why
>> is that necessary, since I already named the toolset on the bjam call?
>>
>> Does anybody know if I can avoid this behaviour so the build still be
>> successfull even though the path is missing?
>>
>
>    It used to be that this was required to work,
> and it still does with some tools, just not gcc.
> The easiest workaround is to check whether the
> path exists:
>
> import path ;
> if [ path.exists /path/to/g++ ]
> {
>      using gcc : /path/to/g++ ;
> }

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 ?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Boost build failed if custom toolset path is not available

Steven Watanabe-4
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.
- 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"
- 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.

  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.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Boost build failed if custom toolset path is not available

Edward Diener-3
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Boost build failed if custom toolset path is not available

Steven Watanabe-4
AMDG

On 02/24/2016 02:57 PM, Edward Diener wrote:

> On 2/24/2016 3:39 PM, Steven Watanabe wrote:
>>
>> - 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 OP apparently was able to diagnose
the problem.

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

a) The first toolset specified is the default,
   which will be run if there is no toolset=xxx
   specified.
b) The using declaration itself doesn't provide enough
   information to distinguish between C++ toolsets
   like gcc that are controlled by <toolset> and
   other tools like xsltproc.  Without actually
   running xxx.init, we can only treat xxx as
   an opaque string, which is basically useless.

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

  The problem is with "when it is determined that
the "xxx" toolset is being used."  The mapping
from command line arguments to the toolset is
set up by the call to using xxx ;.

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

  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.

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

  There used to be a guideline that using xxx ; should
always succeed even if xxx doesn't exist, but this seems
to have been dropped by the wayside.

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

using xsltproc ; does two things:
a) It checks that xsltproc exists, (on windows
   I believe that it also checks whether it's
   cygwin or windows, in order to adjust the
   input paths correctly)
b) It sets up internal Boost.Build structures
   that describe when xsltproc should be run.

(b) is unavoidable, as without it we wouldn't
even recognize when we need to initialize xsltproc.

  What makes this a hard problem is that for
complex toolsets like gcc, (a) and (b) are
heavily intertwined.  i.e. it runs gcc to
find the version number and this deduced
version number can be used by the toolset
selection algorithm.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Boost build failed if custom toolset path is not available

Edward Diener-3
On 2/24/2016 5:45 PM, Steven Watanabe wrote:

> AMDG
>
> On 02/24/2016 02:57 PM, Edward Diener wrote:
>> On 2/24/2016 3:39 PM, Steven Watanabe wrote:
>>>
>>> - 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 OP apparently was able to diagnose
> the problem.
>
>>> - 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.
>>
>
> a) The first toolset specified is the default,
>     which will be run if there is no toolset=xxx
>     specified.
> b) The using declaration itself doesn't provide enough
>     information to distinguish between C++ toolsets
>     like gcc that are controlled by <toolset> and
>     other tools like xsltproc.  Without actually
>     running xxx.init, we can only treat xxx as
>     an opaque string, which is basically useless.
>
>>> - 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.
>>
>
>    The problem is with "when it is determined that
> the "xxx" toolset is being used."  The mapping
> from command line arguments to the toolset is
> set up by the call to using xxx ;.
>
>>
>>>     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.
>
>    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 ), 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 ).

>
>> 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.
>>
>
>    There used to be a guideline that using xxx ; should
> always succeed even if xxx doesn't exist, but this seems
> to have been dropped by the wayside.
>
>> 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.
>>
>
> using xsltproc ; does two things:
> a) It checks that xsltproc exists, (on windows
>     I believe that it also checks whether it's
>     cygwin or windows, in order to adjust the
>     input paths correctly)
> b) It sets up internal Boost.Build structures
>     that describe when xsltproc should be run.
>
> (b) is unavoidable, as without it we wouldn't
> even recognize when we need to initialize xsltproc.

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 ?

>
>    What makes this a hard problem is that for
> complex toolsets like gcc, (a) and (b) are
> heavily intertwined.  i.e. it runs gcc to
> find the version number and this deduced
> version number can be used by the toolset
> selection algorithm.

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

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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Boost build failed if custom toolset path is not available

Steven Watanabe-4
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Boost build failed if custom toolset path is not available

Edward Diener-3
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Boost build failed if custom toolset path is not available

Vladimir Prus-4
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++ ;

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.

Another use case, that we don't 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?

--
Vladimir Prus
http://vladimirprus.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Boost build failed if custom toolset path is not available

Edward Diener-3
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.




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build