[Boost-bugs] [Boost C++ Libraries] #9704: b2: Compiler flavour has no flexibility for cross-compiling projects.

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
-------------------------------+--------------------------------
 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?)

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