Re: [Boost-users] building boost with unsupported compiler

Yep we really do have a completely different compiler\toolchain from any
currently present, with different switches to GCC, different extensions
for compiled objects etc.
Of course bjam doesn't need to be built for the target architecture :)
It's just that while poking around it looked like bjam needed to have
some knowledge about the toolchains it was building for and I suspected
that the .jam files in the directory I mentioned earlier were a means to
do this. Effectively I want to take steps to make our tools one of the
"Builtin tools", mentioned in the help here:
http://www.boost.org/boost-build2/doc/html/bbv2/reference/tools.html, so
our customers can build Boost with our tools without any fuss.
- Sean
Date: Tue, 23 Jun 2009 19:00:05 +0400
From: Vladimir Prus
Hi,
I'm looking to build Boost with a compiler not currently supported, but
I'm struggling to find information on where I should really begin. It
seems that I'll need to create my own toolset module (something like
..../boost_1_39_0/tools/build/v2/tools/blackfin.jam) with the
toolchain's specific build switches etc,
You should only do that if you really have a custom compiler. For gcc port, the 'gcc' toolset is fine.
rebuild bjam then build Boost.
No need to rebuild bjam -- it's a host program.
I presume that boost also has some libraries which may need some
specific options, or tweaking to work but am I getting the gist of it
correctly? Should I be expecting major configuration headaches
(toolchain-specific build\runtime issues aside) in adding a new
architecture?
I would not expect too much problems. I know folks were compiling Boost for arm-linux, in particular, with minor issues. - Volodya

McLemon, Sean wrote:
Yep we really do have a completely different compiler\toolchain from any currently present, with different switches to GCC, different extensions for compiled objects etc.
Then, you really need a new toolset module. However, I suggest basing it on something simple, for example acc.jam. The gcc support is one of the most complex in Boost.Build, in part because gcc works both on Linux and Windows.
Of course bjam doesn't need to be built for the target architecture :) It's just that while poking around it looked like bjam needed to have some knowledge about the toolchains it was building for and I suspected that the .jam files in the directory I mentioned earlier were a means to do this. Effectively I want to take steps to make our tools one of the "Builtin tools", mentioned in the help here: http://www.boost.org/boost-build2/doc/html/bbv2/reference/tools.html, so our customers can build Boost with our tools without any fuss.
You just have to drop a new module into tools directory, and then configure it in user-config.jam, e.g.: using your_compiler : 1.0 : /usr/local/bin/yourcompiler ; and then build with bjam toolset=your_compiler If you have any problems, feel free to ask. I suggest we follow up on a dedicated list for Boost.Build -- boost-build@lists.boost.org. - Volodya

Then, you really need a new toolset module. However, I suggest basing it on something simple, for example acc.jam. The gcc support is one of the most complex in Boost.Build, in part because gcc works both on Linux and Windows.
Yeah, I suspected as much. I did get rather scared after seeing the size of the msvc and gcc modules - using acc.jam is a good idea.
You just have to drop a new module into tools directory, and then configure it in user-config.jam, e.g.:
using your_compiler : 1.0 : /usr/local/bin/yourcompiler ;
and then build with
bjam toolset=your_compiler
Good to hear! Thanks for clarifying everything, Vladimir. - Sean
participants (2)
-
McLemon, Sean
-
Vladimir Prus