From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2007-02-23 06:01:06
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". On windows gcc can be obtained
*) "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).
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.
2) As I have pointed out in my post
"Combo installation of mingw and cygwin. HOWTO." it is possible
to put both flavors of gcc (mingw and cygwin) into the require-
ments of a single bjam invocation, although at the price of being
less intuitive. Also the invocation syntax used seems to be necessary
due to a (already reported) bug in build-system.jam. (The bug
prevents the toolset= syntax.)
3) The usage of the flavor currently is twofold:
*) the tagging of the libraries built in stage target depends on the
flavor being present.
*) Since the flavor becomes part of the toolset name (it is a
subfeature just like version) it can be used in the
boost_root/status/explicit-failures-markup.xml file. While this
issue does not strictly belong to Boost.Build, I suspect a
potential problem if the flavor (or target-os) is not available
to regression testing tools.
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.)
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
*) 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,
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".
*) 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.
*) 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.
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