Boost logo

Boost-Build :

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2008-04-22 06:49:54


Vladimir Prus wrote:
> You mean, even you you request second configured gcc explicitly,
> you'll get the flavour of the first? That's a bug, and I think
> the part of your patch that addresses that is OK.
>
>
I think this "unfortunatley" is not a bug, it just comes as a surprise
to the user. It seems
to be a consequence of how default values are expanded.

E.g. the following definitions in user-config.jam

using gcc
    : 3.4.2
    : "C:/Programme/mingw-3.4.2/bin/g++.exe"
    : <flavor>mingw
      <root>"C:/Programme/mingw-3.4.2/"
      <linkflags>-Wl,--enable-runtime-pseudo-reloc
    ;

using gcc
    : 3.4.4
    : "c:/subsys/cygwin/bin/g++.exe"
    : <root>"c:/subsys/cygwin/"
    ;

and the following invocation:

bjam gcc-3.4.4

cause the correct compiler, i.e. c:/subsys/cygwin/bin/g++.exe being
called, but
it gets a default flavor of mingw, which is not what was expected. This is
because the flavor is only defined for mingw type gcc's.

My suggested fix will only work if _all_ compilers get a flavor during init.
> 1. What additional information will be available that is not
> available now? I presume, the real version?
>
>
I currently have 4 gcc's in use, the -dumpmachine gives:
powerpc-linux a cross compiler
i386-unknown-linux-gnu the native compiler
i686-pc-cygwin gcc targeting cygwin dll's
i686-pc-mingw32 the same gcc targeting msvc dll's
mingw32 the mingw (windows port) compiler

As you can see there is a lot of information, and what is more important, it
is independant of what the user specifies in the version field.

Let assume the user specified, instead of my above definitions:

using gcc
    : cgw
    : "c:/subsys/cygwin/bin/g++.exe"
    : <root>"c:/subsys/cygwin/"
    ;

She would invoke as
bjam gcc-cgw

and conditions the try to condition on <toolset-gcc:version>3.4.4 will
not trigger
any more.
> 2. Why should the flavour be present in the path at all?
>
>
It is not a discussion of why it should, it just is the case at the
moment. I believ this is because
flavor is a subfeature of toolset. My question was if it would be
possible to suppress
the subfeature on the path. I already tried to make toolset an
asymmetric feature, but
for of reasons I do not currently understand, this does not work.

Roland


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