From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2019-07-10 23:56:36
On Wed, Jul 10, 2019 at 8:51 AM Edward Diener via Boost-build <
> 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]>>
> > 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
> > >> 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
> > >> python toolset.
> > >>
> > >> My current method of doing this is to link a 32-bit user-config
> > >> 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
> > > 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
> > 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
> > 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
The usual way around that is to specify a decorated version number on init.
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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk