Re: [Boost-build] Including bjam code based on the address_model

From: Edward Diener (eldiener_at_[hidden])
Date: 2019-07-11 05:46:35

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 
> <boost-build_at_[hidden] <mailto:boost-build_at_[hidden]>> 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
>      > <boost-build_at_[hidden] <mailto:boost-build_at_[hidden]>
>     <mailto:boost-build_at_[hidden]
>     <mailto:boost-build_at_[hidden]>>> 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.