C++ Build Environment using MinGW-w64 and Boost.Build

Question

I'm currently porting one of my projects to GCC, and I'm using the MinGW-w64 project to accomplish this as I require both x64 and x86 support.

I've hit a problem in setting up my build environment though. My project currently uses the Boost C++ libraries, and to make the build process easier I use Boost.Build in my project too (as it makes integration simple).

Under MSVC this is fine, because I can do the following from the command line:

b2 toolset=msvc address-model=32 # compile as 32-bit
b2 toolset=msvc address-model=64 # compile as 64-bit

MinGW-w64 is making this 'problematic', as the 32-bit and 64-bit toolchains are housed in separate directories. (C:\MinGW32 and C:\MinGW64 respectively).

Is it possible to set up Boost.Build in a way that it will choose the correct toolchain based on the address-model flag? If not, what is my next best option?

EDIT:

If it helps, I am using the rubenvb 4.6.3-1 builds from the MinGW-w64 website in the "Personal Builds" folder (I am using these builds in particular as I wish to try getting my code to parse - but not compile - under Clang).

EDIT:

One solution I just thought of would be to 'manually' set the PATH to point to the correct toolchain before compilation, however this adds an extra layer of complication to my build process which I'd like to avoid. Ideally I would like it to be as easy as it is for MSVC, though I understand this may not be possible. In the worst case I assume what I just suggested would work, and I would just have to add scripts to correctly set the PATH before invoking Boost.Build. That would mean hardcoding a path though, which I don't want to do...

Historical

Answer 1

Yo can make any Boost.Build toolset be chosen based on a set of matching properties by adding a toolset requirement (with the toolset.add-requirements rule). There is built-in support for this in some toolsets, like darwin.jam (Xcode), but unfortunately we haven't added that to the gcc toolset yet. But you can use the same minimal code in your user-config.jam when declaring the toolsets. For you case it might look like this:

import toolset ;

using gcc : gcc-4.6.3~32 : /path/to/32bit/mingw/gcc ;
using gcc : gcc-4.6.3~64 : /path/to/64bit/mingw/gcc ;

# Add a global target requirements to "choose" the toolset based on the address model.
toolset.add-requirements <toolset>gcc-4.6.3~32:<address-model>32 ;
toolset.add-requirements <toolset>gcc-4.6.3~64:<address-model>64 ;

This has the effect of adding the given conditional requirement to all the targets. Which has the effect of selecting a particular target for a particular declared toolset as needed.

..Forgot to mention.. That even though this is creating two different toolset declarations the default is still chosen dynamically. One would use the usual command line:

b2 toolset=gcc address-model=64

To use the 64 bit mingw compiler.

Insinuation

Answer 2

Since the MinGW binaries have different names you should be able to include booth directories into the path and then add two different toolsets in the jam configuration file, where you specify the exact names of the binary files (excluding the path).

In the config file add the following based on the format

using gcc : [version] : [c++-compile-command] : [compiler options] ;

using gcc : 32 : mingw-w32-1.0-bin_i686-mingw ;
using gcc : 64 : mingw-w64-1.0-bin_i686-mingw ;

You should then be able to call b2 like this:

b2 toolset=gcc-32
bt toolset=gcc-64

Chutney

Is there any way to do something similar without adding a prefix to the toolchain? I'd like to use the 'default' toolchain name, and have the 32/64-bit part detected by the address-model flag. – Historical

e.g. b2 toolset=gcc address-model=32 – Historical

Not that I know of, address-model is obviously not supported as argument to mingw-gcc. May I ask why using address-model=32 is better in your case? – Chutney

Because I would like to be able to compile my project both under the MinGW-w64 distribution I'm currently using, as well as alternatives like TDM-GCC, which is multilib, and builds both x86 and x64 binaries from the same toolchain. So in that case, I have no choice but to use the address-model flag. Basically, I want a "unified" interface to make maintaining my build environment less of a headache. – Historical

Ok, but you should still be able to supply the address-model in the configuration file for tdm-gcc like: "using gcc : tdm64: tdm-gcc-binary : address-model=64;" "using gcc : tdm32: tdm-gcc-binary : address-model=32;" So when using tdm you call "b2 toolset=gcc-tdm64" or "b2 toolset=gcc-tdm32, when using mingw-w64 "b2 toolset=gcc-32" or "bt toolset=gcc-64" – Chutney

Answer 3

MinGW-w64 can build 32 and 64 bits binaries.

I use tdm-mingw with mingw64 toolchan and only pass -m32 or -m64 to linker / compiler to select version. In default 64 bits binaries are build.

Flycatcher

Unfortunately not all MinGW-w64 builds can do that. As already stated in my question, I'm using the builds by rubenvb which are not multilib, so I have two installations, one for the 32-bit toolchain, and one for the 64-bit toolchain. The 64-bit toolchain can only build 64-bit binaries, and the 32-bit toolchain can only build 32-bit binaries. – Historical