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:
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
> 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
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
> *) 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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk