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
and the following invocation:
cause the correct compiler, i.e. c:/subsys/cygwin/bin/g++.exe being
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:
She would invoke as
and conditions the try to condition on <toolset-gcc:version>3.4.4 will
> 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.
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