Including bjam code based on the address_model

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

Including bjam code based on the address_model

Boost - Build mailing list
I would like to include different bjam code, using the 'include' rule,
into a jamfile based on the address-model used when b2 is invoked. Is
this doable, and if so how ? Would it make any difference if the jamfile
involved were 'user-config.jam' ?

Essentially I need to use different toolset definitions depending on
whether the compile is for 32 bit or 64-bit code and I thought the
easiest way to do this would be just to include different toolset
definitions into my user-config.jam depending on the address model. If
there is a better way to do this within bjam I would love to know what
it is. Most of the toolsets involved are compilers but some are just
other tools such as zip libraries like bzip2 and there is also the
python toolset.

My current method of doing this is to link a 32-bit user-config to
user-config.jam when I do 32-bit compile and a 64-bit user-config to
user-config.jam when I do a 64-bit compile, but this has always seemed
to me to be kludgy even if it does work, and I am hoping that bjam has
the ability to solve this without my kludge.

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

Re: Including bjam code based on the address_model

Boost - Build mailing list
On 7/9/2019 8:47 AM, Edward Diener via Boost-build wrote:

> I would like to include different bjam code, using the 'include' rule,
> into a jamfile based on the address-model used when b2 is invoked. Is
> this doable, and if so how ? Would it make any difference if the jamfile
> involved were 'user-config.jam' ?
>
> Essentially I need to use different toolset definitions depending on
> whether the compile is for 32 bit or 64-bit code and I thought the
> easiest way to do this would be just to include different toolset
> definitions into my user-config.jam depending on the address model. If
> there is a better way to do this within bjam I would love to know what
> it is. Most of the toolsets involved are compilers but some are just
> other tools such as zip libraries like bzip2 and there is also the
> python toolset.
>
> My current method of doing this is to link a 32-bit user-config to
> user-config.jam when I do 32-bit compile and a 64-bit user-config to
> user-config.jam when I do a 64-bit compile, but this has always seemed
> to me to be kludgy even if it does work, and I am hoping that bjam has
> the ability to solve this without my kludge.

Solved ! Evidently with 'using' rule for the various compilers and tools
I can add target alternatives in the requirements section and so can
have <address-model>32 and <address-model>64 to achieve my goal.

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

Re: Including bjam code based on the address_model

Boost - Build mailing list
On 7/9/2019 11:30 AM, Edward Diener via Boost-build wrote:

> On 7/9/2019 8:47 AM, Edward Diener via Boost-build wrote:
>> I would like to include different bjam code, using the 'include' rule,
>> into a jamfile based on the address-model used when b2 is invoked. Is
>> this doable, and if so how ? Would it make any difference if the
>> jamfile involved were 'user-config.jam' ?
>>
>> Essentially I need to use different toolset definitions depending on
>> whether the compile is for 32 bit or 64-bit code and I thought the
>> easiest way to do this would be just to include different toolset
>> definitions into my user-config.jam depending on the address model. If
>> there is a better way to do this within bjam I would love to know what
>> it is. Most of the toolsets involved are compilers but some are just
>> other tools such as zip libraries like bzip2 and there is also the
>> python toolset.
>>
>> My current method of doing this is to link a 32-bit user-config to
>> user-config.jam when I do 32-bit compile and a 64-bit user-config to
>> user-config.jam when I do a 64-bit compile, but this has always seemed
>> to me to be kludgy even if it does work, and I am hoping that bjam has
>> the ability to solve this without my kludge.
>
> Solved ! Evidently with 'using' rule for the various compilers and tools
> I can add target alternatives in the requirements section and so can
> have <address-model>32 and <address-model>64 to achieve my goal.

I spoke too soon. Using the <address-model>32 and <address-model>64 as
target alternatives in toolset 'using' statements does not work to
distinguish 'using' statements with the same name and version. Instead I
get from Boost Build the error of:

error: duplicate initialization of xxx with the following parameters etc.

for toolset 'xxx', as in

using xxx : nnn : some_command : <address-model>32 ;
using xxx : nnn : some_other_command : <address-model>64 ;

I guess I must go back to my original kludge as there seems to be no way
to have Boost Build pick out the correct toolset based on whether I am
compiling with a 32-bit or 64-bit address model.

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

Re: Including bjam code based on the address_model

Boost - Build mailing list
On Tue, Jul 9, 2019 at 7:58 PM Edward Diener via Boost-build <[hidden email]> wrote:
On 7/9/2019 11:30 AM, Edward Diener via Boost-build wrote:
> On 7/9/2019 8:47 AM, Edward Diener via Boost-build wrote:
>> I would like to include different bjam code, using the 'include' rule,
>> into a jamfile based on the address-model used when b2 is invoked. Is
>> this doable, and if so how ? Would it make any difference if the
>> jamfile involved were 'user-config.jam' ?
>>
>> Essentially I need to use different toolset definitions depending on
>> whether the compile is for 32 bit or 64-bit code and I thought the
>> easiest way to do this would be just to include different toolset
>> definitions into my user-config.jam depending on the address model. If
>> there is a better way to do this within bjam I would love to know what
>> it is. Most of the toolsets involved are compilers but some are just
>> other tools such as zip libraries like bzip2 and there is also the
>> python toolset.
>>
>> My current method of doing this is to link a 32-bit user-config to
>> user-config.jam when I do 32-bit compile and a 64-bit user-config to
>> user-config.jam when I do a 64-bit compile, but this has always seemed
>> to me to be kludgy even if it does work, and I am hoping that bjam has
>> the ability to solve this without my kludge.
>
> Solved ! Evidently with 'using' rule for the various compilers and tools
> I can add target alternatives in the requirements section and so can
> have <address-model>32 and <address-model>64 to achieve my goal.

I spoke too soon. Using the <address-model>32 and <address-model>64 as
target alternatives in toolset 'using' statements does not work to
distinguish 'using' statements with the same name and version. Instead I
get from Boost Build the error of:

error: duplicate initialization of xxx with the following parameters etc.

for toolset 'xxx', as in

using xxx : nnn : some_command : <address-model>32 ;
using xxx : nnn : some_other_command : <address-model>64 ;

I guess I must go back to my original kludge as there seems to be no way
to have Boost Build pick out the correct toolset based on whether I am
compiling with a 32-bit or 64-bit address model.

You can add a global toolset requirement to do that selection. Some toolsets initializations take those extra arguments and apply it. For example:

using gcc : : c++ -fx32 : : <address-model>32 ;

But the common ones don't have that, yet. Instead you can go the post init route:

using toolset ;
using clang : 9.1 : g++ ;
toolset.add-requirements <toolset>clang,<address-model>32:<toolset-clang:version>9.1 ;

The syntax for that long requirements might need some tweaking for your use case.

--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net


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

Re: Including bjam code based on the address_model

Boost - Build mailing list
On 7/9/2019 10:01 PM, Rene Rivera via Boost-build wrote:

> On Tue, Jul 9, 2019 at 7:58 PM Edward Diener via Boost-build
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 7/9/2019 11:30 AM, Edward Diener via Boost-build wrote:
>      > On 7/9/2019 8:47 AM, Edward Diener via Boost-build wrote:
>      >> I would like to include different bjam code, using the 'include'
>     rule,
>      >> into a jamfile based on the address-model used when b2 is
>     invoked. Is
>      >> this doable, and if so how ? Would it make any difference if the
>      >> jamfile involved were 'user-config.jam' ?
>      >>
>      >> Essentially I need to use different toolset definitions
>     depending on
>      >> whether the compile is for 32 bit or 64-bit code and I thought the
>      >> easiest way to do this would be just to include different toolset
>      >> definitions into my user-config.jam depending on the address
>     model. If
>      >> there is a better way to do this within bjam I would love to
>     know what
>      >> it is. Most of the toolsets involved are compilers but some are
>     just
>      >> other tools such as zip libraries like bzip2 and there is also the
>      >> python toolset.
>      >>
>      >> My current method of doing this is to link a 32-bit user-config to
>      >> user-config.jam when I do 32-bit compile and a 64-bit
>     user-config to
>      >> user-config.jam when I do a 64-bit compile, but this has always
>     seemed
>      >> to me to be kludgy even if it does work, and I am hoping that
>     bjam has
>      >> the ability to solve this without my kludge.
>      >
>      > Solved ! Evidently with 'using' rule for the various compilers
>     and tools
>      > I can add target alternatives in the requirements section and so can
>      > have <address-model>32 and <address-model>64 to achieve my goal.
>
>     I spoke too soon. Using the <address-model>32 and <address-model>64 as
>     target alternatives in toolset 'using' statements does not work to
>     distinguish 'using' statements with the same name and version.
>     Instead I
>     get from Boost Build the error of:
>
>     error: duplicate initialization of xxx with the following parameters
>     etc.
>
>     for toolset 'xxx', as in
>
>     using xxx : nnn : some_command : <address-model>32 ;
>     using xxx : nnn : some_other_command : <address-model>64 ;
>
>     I guess I must go back to my original kludge as there seems to be no
>     way
>     to have Boost Build pick out the correct toolset based on whether I am
>     compiling with a 32-bit or 64-bit address model.
>
>
> You can add a global toolset requirement to do that selection. Some
> toolsets initializations take those extra arguments and apply it. For
> example:
>
> using gcc : : c++ -fx32 : : <address-model>32 ;
>
> But the common ones don't have that, yet. Instead you can go the post
> init route:
>
> using toolset ;
> using clang : 9.1 : g++ ;
> toolset.add-requirements
> <toolset>clang,<address-model>32:<toolset-clang:version>9.1 ;
>
> The syntax for that long requirements might need some tweaking for your
> use case.

I think you meant to write above

import toolset ;

instead of

using toolset ;

or am I wrong ?

Also the syntax in your example for the add-requirements looks strange
considering it is trying to add <address-model>32 to the clang toolset
with version 9.1. Is it really correct as you specified it ? I would
have guessed logically, without actually knowing the syntax, the order
of the parameter would be:

<toolset>clang,<toolset-clang:version>9.1:<address-model>32 ;

in order to say that for toolset clang with version 9.1 add the
requirement for a 32-bit address model. But what do I know ? Is there
any doc on what a 'requirement', in the toolset add-requirements rule,
is supposed to look like ?

Also if I have, using my OP examples above:

using xxx : nnn : some_command ;
using xxx : nnn : some_other_command ;

where both the toolset name and version are the same, and I want to add
the requirement <address-model>32 to the first and the <address-model>64
to the second, do I achieve this by invoking toolset.add-requirements
with each different address model directly after each one, as in:

using xxx : nnn : some_command ;
toolset.add-requirements with <address-model>32 etc.
using xxx : nnn : some_other_command ;
toolset.add-requirements with <address-model>64 etc.

Thanks very much for your help !

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

Re: Including bjam code based on the address_model

Boost - Build mailing list
In reply to this post by Boost - Build mailing list
On 7/9/2019 10:01 PM, Rene Rivera via Boost-build wrote:

> On Tue, Jul 9, 2019 at 7:58 PM Edward Diener via Boost-build
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 7/9/2019 11:30 AM, Edward Diener via Boost-build wrote:
>      > On 7/9/2019 8:47 AM, Edward Diener via Boost-build wrote:
>      >> I would like to include different bjam code, using the 'include'
>     rule,
>      >> into a jamfile based on the address-model used when b2 is
>     invoked. Is
>      >> this doable, and if so how ? Would it make any difference if the
>      >> jamfile involved were 'user-config.jam' ?
>      >>
>      >> Essentially I need to use different toolset definitions
>     depending on
>      >> whether the compile is for 32 bit or 64-bit code and I thought the
>      >> easiest way to do this would be just to include different toolset
>      >> definitions into my user-config.jam depending on the address
>     model. If
>      >> there is a better way to do this within bjam I would love to
>     know what
>      >> it is. Most of the toolsets involved are compilers but some are
>     just
>      >> other tools such as zip libraries like bzip2 and there is also the
>      >> python toolset.
>      >>
>      >> My current method of doing this is to link a 32-bit user-config to
>      >> user-config.jam when I do 32-bit compile and a 64-bit
>     user-config to
>      >> user-config.jam when I do a 64-bit compile, but this has always
>     seemed
>      >> to me to be kludgy even if it does work, and I am hoping that
>     bjam has
>      >> the ability to solve this without my kludge.
>      >
>      > Solved ! Evidently with 'using' rule for the various compilers
>     and tools
>      > I can add target alternatives in the requirements section and so can
>      > have <address-model>32 and <address-model>64 to achieve my goal.
>
>     I spoke too soon. Using the <address-model>32 and <address-model>64 as
>     target alternatives in toolset 'using' statements does not work to
>     distinguish 'using' statements with the same name and version.
>     Instead I
>     get from Boost Build the error of:
>
>     error: duplicate initialization of xxx with the following parameters
>     etc.
>
>     for toolset 'xxx', as in
>
>     using xxx : nnn : some_command : <address-model>32 ;
>     using xxx : nnn : some_other_command : <address-model>64 ;
>
>     I guess I must go back to my original kludge as there seems to be no
>     way
>     to have Boost Build pick out the correct toolset based on whether I am
>     compiling with a 32-bit or 64-bit address model.
>
>
> You can add a global toolset requirement to do that selection. Some
> toolsets initializations take those extra arguments and apply it. For
> example:
>
> using gcc : : c++ -fx32 : : <address-model>32 ;
>
> But the common ones don't have that, yet. Instead you can go the post
> init route:
>
> using toolset ;
> using clang : 9.1 : g++ ;
> toolset.add-requirements
> <toolset>clang,<address-model>32:<toolset-clang:version>9.1 ;
>
> The syntax for that long requirements might need some tweaking for your
> use case.

Adding a global toolset requirement based on toolset name and version
does not help me because I have two toolset definitions with the same
toolset name and version. Any global toolset requirement of the kind
specified will therefore be applied to both of them, whereas what I
actually want is that one of the two have a requirement for
<address-model>32 while the other of the two has a requirement for
<address-model>64.

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

Re: Including bjam code based on the address_model

Boost - Build mailing list
On Wed, Jul 10, 2019 at 8:51 AM Edward Diener via Boost-build <[hidden email]> wrote:
On 7/9/2019 10:01 PM, Rene Rivera via Boost-build wrote:
> On Tue, Jul 9, 2019 at 7:58 PM Edward Diener via Boost-build
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 7/9/2019 11:30 AM, Edward Diener via Boost-build wrote:
>      > On 7/9/2019 8:47 AM, Edward Diener via Boost-build wrote:
>      >> I would like to include different bjam code, using the 'include'
>     rule,
>      >> into a jamfile based on the address-model used when b2 is
>     invoked. Is
>      >> this doable, and if so how ? Would it make any difference if the
>      >> jamfile involved were 'user-config.jam' ?
>      >>
>      >> Essentially I need to use different toolset definitions
>     depending on
>      >> whether the compile is for 32 bit or 64-bit code and I thought the
>      >> easiest way to do this would be just to include different toolset
>      >> definitions into my user-config.jam depending on the address
>     model. If
>      >> there is a better way to do this within bjam I would love to
>     know what
>      >> it is. Most of the toolsets involved are compilers but some are
>     just
>      >> other tools such as zip libraries like bzip2 and there is also the
>      >> python toolset.
>      >>
>      >> My current method of doing this is to link a 32-bit user-config to
>      >> user-config.jam when I do 32-bit compile and a 64-bit
>     user-config to
>      >> user-config.jam when I do a 64-bit compile, but this has always
>     seemed
>      >> to me to be kludgy even if it does work, and I am hoping that
>     bjam has
>      >> the ability to solve this without my kludge.
>      >
>      > Solved ! Evidently with 'using' rule for the various compilers
>     and tools
>      > I can add target alternatives in the requirements section and so can
>      > have <address-model>32 and <address-model>64 to achieve my goal.
>
>     I spoke too soon. Using the <address-model>32 and <address-model>64 as
>     target alternatives in toolset 'using' statements does not work to
>     distinguish 'using' statements with the same name and version.
>     Instead I
>     get from Boost Build the error of:
>
>     error: duplicate initialization of xxx with the following parameters
>     etc.
>
>     for toolset 'xxx', as in
>
>     using xxx : nnn : some_command : <address-model>32 ;
>     using xxx : nnn : some_other_command : <address-model>64 ;
>
>     I guess I must go back to my original kludge as there seems to be no
>     way
>     to have Boost Build pick out the correct toolset based on whether I am
>     compiling with a 32-bit or 64-bit address model.
>
>
> You can add a global toolset requirement to do that selection. Some
> toolsets initializations take those extra arguments and apply it. For
> example:
>
> using gcc : : c++ -fx32 : : <address-model>32 ;
>
> But the common ones don't have that, yet. Instead you can go the post
> init route:
>
> using toolset ;
> using clang : 9.1 : g++ ;
> toolset.add-requirements
> <toolset>clang,<address-model>32:<toolset-clang:version>9.1 ;
>
> The syntax for that long requirements might need some tweaking for your
> use case.

Adding a global toolset requirement based on toolset name and version
does not help me because I have two toolset definitions with the same
toolset name and version. Any global toolset requirement of the kind
specified will therefore be applied to both of them, whereas what I
actually want is that one of the two have a requirement for
<address-model>32 while the other of the two has a requirement for
<address-model>64.

The usual way around that is to specify a decorated version number on init. For example:

using clang : 9.1~32 : c++ ;

But I'm curious.. What are you doing that it needs to be this way instead of some other regular feature selection?

--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net


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

Re: Including bjam code based on the address_model

Boost - Build mailing list
On 7/10/2019 7:56 PM, Rene Rivera via Boost-build wrote:

> On Wed, Jul 10, 2019 at 8:51 AM Edward Diener via Boost-build
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 7/9/2019 10:01 PM, Rene Rivera via Boost-build wrote:
>      > On Tue, Jul 9, 2019 at 7:58 PM Edward Diener via Boost-build
>      > <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>> wrote:
>      >
>      >     On 7/9/2019 11:30 AM, Edward Diener via Boost-build wrote:
>      >      > On 7/9/2019 8:47 AM, Edward Diener via Boost-build wrote:
>      >      >> I would like to include different bjam code, using the
>     'include'
>      >     rule,
>      >      >> into a jamfile based on the address-model used when b2 is
>      >     invoked. Is
>      >      >> this doable, and if so how ? Would it make any difference
>     if the
>      >      >> jamfile involved were 'user-config.jam' ?
>      >      >>
>      >      >> Essentially I need to use different toolset definitions
>      >     depending on
>      >      >> whether the compile is for 32 bit or 64-bit code and I
>     thought the
>      >      >> easiest way to do this would be just to include different
>     toolset
>      >      >> definitions into my user-config.jam depending on the address
>      >     model. If
>      >      >> there is a better way to do this within bjam I would love to
>      >     know what
>      >      >> it is. Most of the toolsets involved are compilers but
>     some are
>      >     just
>      >      >> other tools such as zip libraries like bzip2 and there is
>     also the
>      >      >> python toolset.
>      >      >>
>      >      >> My current method of doing this is to link a 32-bit
>     user-config to
>      >      >> user-config.jam when I do 32-bit compile and a 64-bit
>      >     user-config to
>      >      >> user-config.jam when I do a 64-bit compile, but this has
>     always
>      >     seemed
>      >      >> to me to be kludgy even if it does work, and I am hoping that
>      >     bjam has
>      >      >> the ability to solve this without my kludge.
>      >      >
>      >      > Solved ! Evidently with 'using' rule for the various compilers
>      >     and tools
>      >      > I can add target alternatives in the requirements section
>     and so can
>      >      > have <address-model>32 and <address-model>64 to achieve my
>     goal.
>      >
>      >     I spoke too soon. Using the <address-model>32 and
>     <address-model>64 as
>      >     target alternatives in toolset 'using' statements does not
>     work to
>      >     distinguish 'using' statements with the same name and version.
>      >     Instead I
>      >     get from Boost Build the error of:
>      >
>      >     error: duplicate initialization of xxx with the following
>     parameters
>      >     etc.
>      >
>      >     for toolset 'xxx', as in
>      >
>      >     using xxx : nnn : some_command : <address-model>32 ;
>      >     using xxx : nnn : some_other_command : <address-model>64 ;
>      >
>      >     I guess I must go back to my original kludge as there seems
>     to be no
>      >     way
>      >     to have Boost Build pick out the correct toolset based on
>     whether I am
>      >     compiling with a 32-bit or 64-bit address model.
>      >
>      >
>      > You can add a global toolset requirement to do that selection. Some
>      > toolsets initializations take those extra arguments and apply it.
>     For
>      > example:
>      >
>      > using gcc : : c++ -fx32 : : <address-model>32 ;
>      >
>      > But the common ones don't have that, yet. Instead you can go the
>     post
>      > init route:
>      >
>      > using toolset ;
>      > using clang : 9.1 : g++ ;
>      > toolset.add-requirements
>      > <toolset>clang,<address-model>32:<toolset-clang:version>9.1 ;
>      >
>      > The syntax for that long requirements might need some tweaking
>     for your
>      > use case.
>
>     Adding a global toolset requirement based on toolset name and version
>     does not help me because I have two toolset definitions with the same
>     toolset name and version. Any global toolset requirement of the kind
>     specified will therefore be applied to both of them, whereas what I
>     actually want is that one of the two have a requirement for
>     <address-model>32 while the other of the two has a requirement for
>     <address-model>64.
>
>
> The usual way around that is to specify a decorated version number on
> init. For example:
>
> using clang : 9.1~32 : c++ ;

Yes, I have done this in the past, but it not guaranteed to work as I
understand it so it also seems like a possibly kludgy solution. If the
toolset actually checks the version number against a compiler's version
number the decorated version number will not match, unless of course
there is logic that extracts the version number from the extra
decoration. I realize that most toolsets do not even check the version
number in any way, but that does not seem guaranteed for all cases but
is very toolset specific.

>
> But I'm curious.. What are you doing that it needs to be this way
> instead of some other regular feature selection?

How would I do this with feature selection ? Remember that my original
problem is that if I have:

using xxx : nnn : some_command ;
using xxx : nnn : some_other_command ;

where xxx and nnn are the same in both cases but the commands are
different, I want to have the first toolset chosen when the invocation is

b2 toolset=xxx-nnn address-model=32

and the second toolset chosen when the invocation is:

b2 toolset=xxx-nnn address-model=64

The reason I need this to happen is that "some_command" sets up the
32-bit 'compiler/tool' for toolset xxx-nnn while 'some_other_command'
sets up the 64-bit 'compiler/tool' for toolset xxx-nnn. I realize it
might be bad form for a compiler or a tool to need separate setups for
32-bit and 64-bit compilation but there are still a number of these that
do, with Intel C++ being an obvious example but there are some others
also. I do understand that the logic for 32-bit versus 64-bit setup may
already be in a toolset's jamfile, but this is not guaranteed for every
toolset. Even when it is in the toolset's jamfile it is rarely documented.

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

Re: Including bjam code based on the address_model

Boost - Build mailing list
On Thu, Jul 11, 2019 at 12:46 AM Edward Diener via Boost-build <[hidden email]> wrote:
I do understand that the logic for 32-bit versus 64-bit setup may
already be in a toolset's jamfile, but this is not guaranteed for every
toolset. Even when it is in the toolset's jamfile it is rarely documented.

Let's reset a bit.. Since it's the intel-win toolset you're mucking with lets make it support the toolset requirements directly first. And then we can find a way to support that use case. Supporting the requirements is as easy as:

* Adding the extra "requirement *" argument to the init. Ex: <https://github.com/boostorg/build/blob/develop/src/tools/gcc.jam#L151>
* Passing that to "check-init-parameters". Ex: <https://github.com/boostorg/build/blob/develop/src/tools/gcc.jam#L278>

From there one can optionally add custom handling of default requirements. For example a default target-os: <https://github.com/boostorg/build/blob/develop/src/tools/gcc.jam#L284>

--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net


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