Subject: [Boost-bugs] [Boost C++ Libraries] #9704: b2: Compiler flavour has no flexibility for cross-compiling projects.
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2014-02-24 20:39:19
#9704: b2: Compiler flavour has no flexibility for cross-compiling projects.
Reporter: lukasz.forynski@â¦ | Type: Bugs
Status: new | Milestone: To Be Determined
Component: Building Boost | Version: Boost 1.54.0
Severity: Problem | Keywords: boost build system
I've been trying hard, but it is annoying, didn't find it elsewhere and it
could really be improved.
I am building my project (i.e. all of my project tree)
on 2 platforms:
for 3 different platforms:
* Linux IA32
* Linux ARM HF
Now, whilst b2 subsystem is quite flexible in specifying different types
of compilers, it is not so much when using the same type of compiler, but
using different versions of it.
I have managed to define it somehow, i.e. in my project_config.jam (@ home
if [ os.name ] = NT
using gcc : : :
using gcc : armhf : arm-linux-gnueabihf-g++.exe :
if [ os.name ] = LINUX
using gcc : : :
using gcc : armhf : /usr/bin/arm-linux-gnueabihf-g++ :
But now, in every sub-project, where I'm moving files to a 'release'
location, (* and whenever I need to specify copmiler-flavor specific
configuration) I need to perform something like:
Is there a better way of doing it?
If not, then the problem (and I guess a bug) is that b2 behaves
differently on different platforms, somewhat lacks of mechanism to support
what I need to do (and it's not really very uncommon).
1. Different toolset names when building on different OSes (and yes, I did
try to specify a default flavor, but see Problem 2).
|| || command || toolset
|| flavor ||
|| gcc XA32(linux) || b2 || gcc
|| 4.7 ||
|| gcc XA32(win) || b2 ||
gcc-4.7.2-mingw || ? ||
|| '''gcc armhf(linux)''' || '''b2 --toolset=gcc-armhf''' || '''gcc'''
|| '''armhf''' ||
|| gcc armhf(win) || b2 --toolset=gcc-armhf target-os=linux || gcc-
mingw-armhf || ? ||
Only gcc-armhf seems to achieve requested results. BUt the main issue it,
that it is all different on different platforms, and both: armhf should
produce compatible binaries.
BTW: is there really a need to distinguish between e.g. Cygwin and MinGW
flavours if they produce the same target with the same version of
compiler? If one builds from Cygwin and MinGW for the same platform:
resulting executables should be compatible for the same target, so only in
'bin' build directory they can really be different (if needed), but it is
unlikely that one builds both of them (target:gcc version) at the same
time (like it is unlikely that I build under windows and linux at the same
2. It is not possible to specify a flavor for GCC (by explicitly giving it
a name and compiler location) - because b2 is performing a version check.
This check either fails, or if it does not (and default version is used) -
automatic build-platform-specific flavor value is created behind the
control) - probably because b2 is trying to be too clever at this.
Couldn't it leave it alone, and use flavor that was explicitly specified?
I really wish that I could specify above:
using gcc : 4.7 : <my-path-to-gcc47> ... ;
using gcc : armhf : <my-path-to-gcc47 arm hf> ... ;
and wouldn't have to create links or worry about the build system
changing/ coming up with a flavor by concatenating target name (e.g. on
with g++ (and having to hack/create symlinks to match this etc.) -
It should just accept what I specify, and use it 'as-is' (and if someone
does something stupid - let them fail and fix it).
There could also be a support for something like:
import toolset ;
if [ toolset.name ] == gcc
if [ toolset.flavor ] == flav_1
# and my verbosive Jamfiles could be re-written to something like:
local gcc_flavor = [ toolset.flavor ] ;
# or even to:
With a bit of guidance / advice from someone, who knows the build system
well - I'm happy to help with implementing the above.
(BTW: what is the best component for build system / tools?)
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/9704> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:15 UTC