Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2007-03-19 12:54:59

on Fri Feb 23 2007, Rene Rivera <> wrote:

> To summarize my overall POV in case it gets lost in my responses
> below... host-os, target-os, and flavor are all independent variables in
> describing a compiler's behavior. Hopefully host-os and target-os are
> self explanatory, which leaves flavor. Since I came up with it here's
> what I mean it to be:
> "flavor"
> A variation of the particular compiler for a particular host-os and
> target-os combination. This can apply to compilers that are either:
> frontends emulating a single compiler and dispatching to backend
> compilers, or different versions of the same compiler that behave
> differently irrespective of all other factors.

I agree with that perspective.

> Roland Schwarz wrote:
>> The current handling of the gcc in Boost.Build currently looks
>> troublesome to me. I try to restate the problems I see and hopefully
>> lead to a discussion of how these problems can be overcome.
>> 1) various flavors of gcc:
>> gcc can be configured as a cross compiler, although I don't think
>> this strictly relates to "flavor".
> I think cross-compiling is a host-os/target-os matter.


>> On windows gcc can be obtained
>> as a
>> *) "mingw" excutable, where the compiler itself depends on
>> msvcrt.dll. This mingw flavor also is able only to produce
>> target code, that depends on msvcrt.dll. Gcc as
>> *) "cygwin" executable, where the compiler itself depends on
>> cygwin1.dll, can produce target code that either depends on
>> cygwin1.dll (the default) or msvcrt.dll (using switch -mmo-cygwin).
> AFAIK what the -mno-cygwin switch does is tell the frontend to call the
> mingw executables, which are part of the cygwin distribution, to do the
> compiles and links.

If that's what you mean by "flavor," I dig it. I was under the
impression that "flavor" was being used to select cygwin or windows
targets for generation by gcc, which is properly the role of

>> The cygwin exe can be invoked from either the cygwin bash or from
>> CMD.EXE. When invoked from CMD.EXE one must make sure that the
>> cygwin1.dll and other helper dlls can be found, e.g. by putting
>> them into PATH environment variable.
>> Since gcc is available on a lot of platforms it is not obvious if
>> *) "native" executable should be the flavor on these platforms,

IMO "flavor" should not be used to describe the type of executable
generated. That's a target-os issue.

>> I'd rather guess a more specific name like linux, or similar
>> being more appropriate.
> Perhaps... We decided not to add a flavor unless needed because when a
> flavor is specified it ends up in the toolset name. This caused, since I
> initially added the flavor for all GCC version, the regression markup to
> become invalid and to general confusion when the toolset specified did
> not match the user visible toolset name (you mention part of this below
> also). But if we want to go back to having the flavor specified we would
> need to be careful in choosing labels to stay away from
> host-os/target-os terms. So "linux" is right out, "posix" might be an
> alternative.


>> 4) Problems with the flavor approach:
>> If you request an incomplete specification from the bjam cmdline:
>> e.g.: bjam gcc-3.4.4, with having configured two toolset's:
>> using gcc : 3.4.2 ;
>> using gcc : 3.4.4 ;
>> you always will get the flavor of the first configured compiler,
>> which is plain wrong. In this case the flavor of 3.4.2, which
>> might be different than 3.4.4.
>> The request bjam gcc-3.4.4-mingw in contrast is complete and will
>> work correctly. (Note again: bjam toolset=gcc-3.4.4-mingw does
>> currently not work either.)
> That's not a problem, that's a *bug*.

Can we fix it? I am running into a similar problem with Python
configuration, although I'm not quite as convinced it's a bug. We may
be missing a feature required to express what we want to do.

>> 5) host-os and target-os features.
>> As already has been suggested by Dave in another post, I too think
>> using these features in the context of cygwin/mingw will be
>> beneficial. My thoughts about this approach:
>> *) host-os and target-os must be somehow set by default, similar
>> as "debug" is getting set by default. So if a user does not
>> mention them explicitely they nevertheless get into the build
>> request.
> They already do. Both have, as the always set default, the running
> OS.

Except the code to set that was broken. I fixed it recently in the RC
branch (but not in HEAD).

> The detection of what the running OS is might need improvement
> though. Although host-os is optional at the moment, to prevent it
> from showing up in the build path.
>> *) While host-os and target-os can describe what the target
>> requirements are, I can see no way how to find out if a
>> given compiler will be able to perform the requested operation,
> I think that's a general problem of build systems. Short of carefully
> interrogating the compiler, or pre-testing the capabilities (ala
> autoconf) we have to rely on users assertions about the tools available.
> Of course I note that this is easier for some compilers, notably msvc,
> as they have well defined capabilities.
>> by considering these two properties alone:
>> E.g. host-os=windows target-os=cygwin . The "cygwin" executable
>> can do this while the "mingw" executable is not capable of producing
>> the requested target. Consequently there must be something that
>> identifies the compiler. E.g. a "flavor".
> It is possible to build a mingw cross-compiler that would allow
> production of such a combination. But this would still be a mingw
> flavor. This leads to credence to using only host-os/target-os, and
> making cygwin an OS variant. But this still doesn't account for the
> possibility of having many other GCC compilers that can produce the
> windows->windows combination, the windows->cygwin, or the
> cygwin->windows combination.

Right, e.g. conceptgcc, just for one.

>> *) The host-os and target-os I suspect need to be present in the
>> physical path names of the file targets. This will make the
>> pending path length problem even worse.
> I posted a variety of proposals on how to remedy the path length problem
> over the past year. I think the last one has the most potential.

We do have --abbreviate-paths, FWIW.

Dave Abrahams
Boost Consulting

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