On Sun, 3 Jul 2011 17:47:02 +0200 Robert Millan <r...@debian.org> wrote:
> 2011/7/3 Robert Millan <r...@debian.org>: > > 2011/7/3 Alexander Kabaev <kab...@gmail.com>: > >> Not really, unless you have way of sticking this definition into > >> past compiler releases. > > > > There is one way, but it's slow. It basically involves waiting for > > long enough that any past release of any compiler you care about > > includes the macros you need, before starting to use them. :-) > > However, in the case of FreeBSD, where the compilers are imported into > your codebase, isn't it enough if support is present in the FreeBSD > version of these compilers (for production and development releases of > FreeBSD), plus the latest release of the upstream version of each of > those compilers? > > -- > Robert Millan The slow way would be the right way if you were inclined to really take it. Once old releases of tools that can be broken by the new macro use are long and forgotten we can start on relying on said macro, but not before. I disagree with the notion that we supporting only the imported compiler version is sufficient in FreeBSD. This was a long time deficiency of our development policy and it did more harm than good in the long term. We do want FSF source releases to work work out of the box, and when they do not, it is our loss. I know for a fact that several of our bigger customers are using compilers built for them by a third party and do not rely on the toolchain we supply in source tree. Breaking them would be bad. -- Alexander Kabaev
signature.asc
Description: PGP signature
