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

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

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

Roland