id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
9704	b2: Compiler flavour has no flexibility for cross-compiling projects.	lukasz.forynski@…	Steven Watanabe	"Hi,

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:
 * Windows, 
 * Linux,

for 3 different platforms:
 * Windows
 * 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 dir):

{{{
if [ os.name ] = NT
{
using gcc : : :
     <cxxflags>-std=c++11 
     <cxxflags>""-include cmath""
     <cxxflags>-Wdeprecated-declarations
    ;

using gcc : armhf : arm-linux-gnueabihf-g++.exe :
     <cxxflags>-std=c++11
     <cxxflags>""-include cmath""
     <cxxflags>-Wdeprecated-declarations
    ;
}

if [ os.name ] = LINUX
{
using gcc : : :
     <cxxflags>-std=c++11 
     <cxxflags>""-include cmath""
    ;

using gcc : armhf : /usr/bin/arm-linux-gnueabihf-g++ :
     <cxxflags>-std=c++11 
     <cxxflags>""-include cmath""
     <cxxflags>-Wdeprecated-declarations
    ;
}
}}}

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:

{{{
install copy_binaries_to_release
  : 
    target_names..
  :
    <target-os>linux:<toolset-gcc:version>4.7:<location>../../release/
    <target-os>windows:<toolset>gcc-4.7.2-mingw:<location>../../release/
    <toolset-gcc:version>armhf:<location>../../release_armhf/
    <toolset>gcc-mingw-armhf:<location>../../release/
  ;
}}}

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).

Problems:
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 time).

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 
{{{
b2 --toolset=gcc-armhf
}}}
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 ] ;
install copy_binaries_to_release
  : 
    target_names..
  :
    <toolset>gcc,<flavor>4.7:<location>../../release
    <toolset>gcc,<flavor>armhf:<location>../../release_$(gcc_flavor)
    
    # or even to:
    <toolset>gcc:<location>../../release_$(gcc_flavor)
  ;
}}}

With a bit of guidance / advice from someone, who knows the build system well - I'm happy to help with implementing the above.

Thanks,
LUkasz.

(BTW: what is the best component for build system / tools?)



"	Bugs	assigned	To Be Determined	build	Boost 1.54.0	Problem		boost build system