Subject: Re: [Boost-build] How best to combine "using xxx", toolset invocation, and conditions?
From: Jess Peterson (jess_at_[hidden])
Date: 2013-12-24 07:17:36
The situation is actually a little worse than I thought. The first
<flavor> added to a "using gcc" statement, whether done explicitly or by
using a compiler that generates *mingw* with -dumpmachine, is used in the
output directory names of every compile. If you try to add a flavor to
each "using gcc" statement then b2 comes up with a compile line that has
options but no compiler.
Removing the following lines from gcc.jam fixes all these problems for me,
but I do not know why they are there nor do I know how to run tests.
# switch $(machine:L)
# case *mingw* : flavor ?= mingw ;
On Tue, Dec 24, 2013 at 4:54 AM, Jess Peterson <jess_at_[hidden]> wrote:
> Thank you for the explanation. There is a bug in gcc.jam, since if I have
> a project-config.jam file with:
> using gcc ;
> using gcc : mingw : /opt/mxe/usr/bin/i686-pc-mingw32-g++ ;
> and a Jamroot with:
> exe hello : hello.cpp ;
> and invoke with "b2 toolset=gcc-mingw", then I get both compilers added to
> "g++" "/opt/mxe/usr/bin/i686-pc-mingw32-g++" -o
> "bin/gcc-mingw-4.4.7/debug/hello" -Wl,--start-group -Wl,--start-group
> "bin/gcc-mingw-4.4.7/debug/hello.o" -Wl,-Bstatic -Wl,-Bstatic
> -Wl,-Bdynamic -Wl,-Bdynamic -Wl,--end-group -Wl,--end-group -g
> It turns out that choosing "mingw" as my toolset version was not a
> fortunate choice since there is special treatment in gcc.jam that sets the
> flavor to mingw if the target machine has a mingw in it. Any other name
> works as expected.
> Flavor is not used to find a toolset so toolset=gcc-mingw does not work no
> matter what is chosen as a version. Also flavor adds a tag at the end of
> the condition (<toolset>gcc-version-flavor) and produces a build at
> .../gcc-flavor-version/... so it is a little confusing.
> As an aside, when I made my little test case above, I first put the using
> lines in the Jamroot and invoked with --ignore-config. The first thing
> that happened is that it found a project-config.jam from a directory far
> above my little test directory, so I added an empty project-config.jam.
> The next thing is that the using lines are ignored if they are in the
> Jamroot file. I am not sure why this happens, but I moved the using lines
> to the local project-config.jam.
> Shouldn't using Jamroot, instead of Jamfile, make the current directory
> the root of the project so b2 should not look higher for a
> Shouldn't --ignore-config make it not look for a project-config.jam as
> well as site-config.jam and user-config.jam?
> Is there any documentation on project-config.jam and what it normally
> On Mon, Dec 23, 2013 at 9:26 AM, Steven Watanabe <watanabesj_at_[hidden]>wrote:
>> On 12/23/2013 02:59 AM, Jess Peterson wrote:
>> > Sometimes, in jamfiles it is necessary to specify flags based on
>> > It would be nice if those toolset conditions matched the various
>> > initializations. That is, it would be nice if I could say something
>> > "using gcc : w32cross : /dir/xxx" and on the command line "b2
>> > toolset=gcc-w32cross" and in a condition
>> > but it does not seem to work that way. In particular the gcc.jam file
>> > gcc a couple of times to get the machine and version and then creates a
>> > condition like gcc-4.8.1-mingw sometimes using the undocumented
>> > Unless the generated condition is used in b2 invocation and in
>> > build lines I have problems getting it to do the right thing. For
>> > if I do not specify a version in the "using" statement, then it will
>> > one into the condition, which might mean that the various conditions in
>> > Jamfiles need to change to make sure the toolset is matched. If I
>> > a version number, gcc.jam will check the compiler version and warn if
>> > version does not match. If I specify a tag for the version, gcc.jam
>> > generate a toolset-condition such as "gcc-mingw-mingw" for "using gcc :
>> > mingw : /xxx/g++" which must be specified rather than "gcc-mingw" or it
>> > combines with the default and tries to compile with two invocations in a
>> > row ("g++" "/xxx/g++" ...). All this has led me to some questions:
>> gcc-mingw-mingw should be a hard error, because
>> subfeatures are required to be unique. Try
>> using something other than "mingw."
>> > 1) Is this the way it is supposed to work or am I missing something
>> > fundamental?
>> > 2) How does the compiler that is actually used get picked out of the
>> > various ones defined in "using" statements?
>> 1) using adds the specified (or deduced) version to
>> the valid values of <toolset-gcc:version>. The
>> first value seen is the default.
>> 2) using also sets up a rule that says, "if <toolset>gcc
>> <toolset-gcc:version>xxx is present in the target
>> properties then append /path/to/g++xxx to the variable
>> CONFIG_COMMAND (which is used by gcc.compile.c++)"
>> It should never be possible to have more than one
>> match (i.e. if multiple gcc versions appear on the
>> command line, then it's a bug in the gcc toolset).
>> 3) b2 toolset=gcc-4.8.2 sets the features <toolset>gcc
>> 4) b2 toolset=gcc sets <toolset>gcc, then <toolset-gcc:version>
>> is set to its default value (the first one initialized--see (1)).
>> 5) b2 sets <toolset> to its default value (we'll assume that
>> gcc is the first toolset). Then the subfeature <toolset-gcc:version>
>> is also set to its default value.
>> > 3) I would think that the best way for it to work would be to say "using
>> > gcc : mytag : ..." and then say "b2 toolset=gcc-mytag" which some
>> > seem to indicate should work. If I want it to work this way, should I
>> > change gcc.jam so that the condition it generates is
>> It's supposed to work, and I don't think I've ever
>> had a problem with it. There may be a problem if
>> you're declaring both mingw and non-mingw.
>> In Christ,
>> Steven Watanabe
>> Unsubscribe & other changes:
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