Re: [Boost-build] Usage of host-os and target-os for toolset gcc ?

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2007-02-23 13:08:59

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.

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.

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

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

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

>     *) The target-os and host-os will not be available as part of the
>        toolset name. (They are not a subfeature of toolset I guess.)
>     This might be a problem for boost regression testing since the
>     only property for markup seems to be the toolset name.

This is certainly a solvable problem... It just takes putting in the 
appropriate info into the XML results and having the markup allow use of 
more info in the XML results.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo