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@boulder.com> 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 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