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 CONFIG_COMMAND

"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 project-config.jam?

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 contains?

Thanks,

Jess

On Mon, Dec 23, 2013 at 9:26 AM, Steven Watanabe <watanabesj@gmail.com> wrote:

AMDG

On 12/23/2013 02:59 AM, Jess Peterson wrote:
> Sometimes, in jamfiles it is necessary to specify flags based on toolset.
> It would be nice if those toolset conditions matched the various "using"
> initializations. That is, it would be nice if I could say something like
> "using gcc : w32cross : /dir/xxx" and on the command line "b2
> toolset=gcc-w32cross" and in a condition "<toolset>gcc-w32cross:<cflags>-w"
> but it does not seem to work that way. In particular the gcc.jam file runs
> 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 <flavor>.
> Unless the generated condition is used in b2 invocation and in conditional
> build lines I have problems getting it to do the right thing. For example,
> if I do not specify a version in the "using" statement, then it will insert
> 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 specify
> a version number, gcc.jam will check the compiler version and warn if the
> version does not match. If I specify a tag for the version, gcc.jam will
> 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
<toolset-gcc:version>4.8.2.
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 examples
> 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 "<toolset>gcc-mytag?
>

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: http://lists.boost.org/mailman/listinfo.cgi/boost-build