Boost logo

Boost-Build :

Subject: Re: [Boost-build] Problem with mingw flavour
From: Mat Marcus (mat-lists_at_[hidden])
Date: 2008-11-03 15:33:00

On Mon, Nov 3, 2008 at 12:06 PM, Vladimir Prus <ghost_at_[hidden]> wrote:
> Assuming I'm on Windows, should

> bjam target-os=linux

> work (setting architecture to arm), or fail? I don't really
> know,
> but probably we should not be very smart, and fail.

I would like to mention a possibly related use case that's important
in my environment. I do much of my work from a cygwin bash shell on
windows. My clients tend to use cmd.exe, so I also test in that shell.
For both shells I generally use a bjam.exe built with msvc. I commonly
use an msvc 8 and an msvc 9 toolset, as well as some hand-built
(non-mingw) gcc toolsets. My user-config.jam looks includes these
lines (and some others):

using msvc : 9.0 : "C:/Program Files/Microsoft Visual Studio
9.0/VC/bin/cl.exe" ;
using msvc : 8.0 : "C:/Program Files/Microsoft Visual Studio 8/VC/bin/cl.exe" ;
using gcc : 4.3.0 : /opt/gcc-4.3.0/bin/g++.exe ;

I have some degree of success sharing with this single
user-config.jam, regardless of whether I am building from the bash
shell or cmd.exe. I've even used a cygwin-built bjam tool under this
configuration, IIRC.

The main problem that I experience has to do with assumptions made
regarding mingw and threading. Since boost 1.35.0 or so, I've needed
to add these lines to my user-config.jam:

  <toolset>msvc:<threadapi>win32 ;

  <toolset>gcc:<threadapi>pthread ;

This allows the thread library to build properly regardless of "host
shell" or how bjam was compiled. However, this has the side effect of
using different paths for build artifacts according to which shell is
being used to build. This doubles the space and time required to
maintain boost and my libraries, even though the same artifacts are
being generated.

In summary, I am requesting that: No matter how bjam is compiled, and
no matter which shell is being used to do the building, I would like a
(shared) single set of artifacts for a given toolset/invocation. It
would also be nice not to require my users to use the
toolset.add-requirements hack (or to add extra options when invoking

 - Mat

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at