Re: [Boost-build] How best to combine "using xxx", toolset invocation, and conditions?

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
> 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_at_[hidden]>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
>>
>
>