From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-04-22 03:03:16
On Monday 21 April 2008 21:12:56 Roland Schwarz wrote:
> Currently it is hard to condition on a specific
> incarnation of gcc.
> While it is possible to condition on a certain
> version of gcc, this still is unreliable, since
> the version is, what the user specifies in
> A special subfeature named <flavor> exists, mainly
> to disambiguate between mingw and "normal" gcc's.
> The flavor still has it's shortcoming though, since
> if not explicitly requested, it will get the value
> of the first configured gcc. This most likely will
> come to a surprise of the user.
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.
> Since the flavor is just a special case of
> -dumpmachine I suggest making flavor more general,
> i.e. make flavor the string that is returned by
> -dumpmachine for all gcc's.
> The incarnation of gcc can be uniquely referenced,
> which is of particular importance in cross builds.
> (Where mingw/cygwin is only a special case.)
> It is mostly compatible, i.e. the lib tagging
> continues to work as current.
> The directory names are getting longer, since flavor
> is a non-incidental feature.
> Is there a way to make the feature assymetric, so that
> the default gcc would not suffer from the longer names?
> I attach a diff to current gcc.jam to this mail.
> I am interested to hear what you think about this proposal.
1. What additional information will be available that is not
available now? I presume, the real version?
2. Why should the flavour be present in the path at all?
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