Boost logo

Boost-Build :

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2007-02-21 13:27:44

David Abrahams wrote:
> [ followups to the boost-build list, please ]
> Roland Schwarz <roland.schwarz_at_[hidden]> writes:

>> only builds on top of this. :-(
> On top of what?

Oh sorry, perhaps my English is not good enough. What I tried to say:

1) I said cygwin/mingw support in Boost.Build v2 is (uhm) sub-optimal.

2) The previous poster (I think it was you) said that "Python support in
BBv2 on Windows and Cygwin is a total mess".

3) My conclusion was that 2) only builds on top of this ( where this is
point 1) ).

>> 1) should cygwin / mingw tag be a
>> *) part of the toolset name like in intel-win intel-linux
> No. win/linux is not really part of the toolset name; it's a
> subfeature of toolset=intel. However, that role should more properly
> be played by the "target-os" feature IMO.

Hmm, at least I do see

files in the tool directory, where intel alone just automagically
forwards, depending on the OS. But I might just misunderstand what a
toolset name really is.

>> 2) Shouldn't cygwin/mingw rather be modelled as a stdlib property?
>> stdlib=native/cygwin/mingw
> No; it has almost nothing to do with the C++ standard library.

I guessed that. It indeed is the runtime lib which is more kind of
target OS. (property rtlib=native,cygwin,mingw ? But target OS I believe
is better.)

> Volodya and I discussed this just now. We agree with you about point
> 3. Here's what we came up with, to address this issue.
> * -mno-cygwin really should be controlled by target-os. Cygwin and
> Win32 are best viewed as different OSes, since Cygwin provides a
> POSIX API. When using a version of Cygwin GCC that supports
> -mno-cygwin, by default it should target the host OS.

This sounds very reasonable to me.

> That is,
> when building from a cygwin bjam, the default would be not to pass
> -mno-cygwin, and when building from a Win32 bjam,

Sorry don't understand. What exactly do you mean by a "cygwin bjam" or
"win32 bjam"?

What would be the default when I invoke from CMD.EXE (I guess win32
bjam, but could also be cygwin bjam) using C:\Cygwin\bin\g++.exe?

> the default would
> be to pass -mno-cygwin. In either case, the default would be
> overridable by passing target-os=...

Hmm, would this allow e.g

   bjam toolset=gcc-3.4.4-cygwin,gcc-3.4.4 stage

if I want both cygwin and "native" target os?

> * If we drop the ability to arbitrarily choose a version string, we
> need a way to identify different configurations of a toolset that
> may have the same version number. For example:
[snipped examples]
> The solution we came up with is to add an optional argument to
> "using" that allows you to create a special toolset subfeature
> on-the-fly, something like:
> using gcc : 3.4 : /usr/local/conceptgcc/bin/g++ : conceptgcc ;
> This feature could then also be used to identify the toolset on the
> command-line, something like:
> bjam toolset=conceptgcc

We need something

1) library authors can use to mark up in explicit-failures-markup.xml
2) library authors can use in Jamfiles.

For 1) a kind of simple pattern matching is available. e.g. gcc-cygwin*
(Will the subfeature be visible in this context?)

For 2) a similar substring matching sometimes looks advantageous. But I
do not know if this just would be kind of opening Pandoras box.


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