This is the mail archive of the
mailing list for the GCC project.
Re: Remove obsolete Tru64 UNIX V5.1B fixinclude support
- From: Bruce Korb <bkorb at gnu dot org>
- To: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, GCC <gcc at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Arnaud Charlet <charlet at adacore dot com>, Tristan Gingold <gingold at adacore dot com>
- Date: Mon, 05 Mar 2012 09:29:09 -0800
- Subject: Re: Remove obsolete Tru64 UNIX V5.1B fixinclude support
- References: <yddsjhnrngz.fsf@manam.CeBiTec.Uni-Bielefeld.DE>
On 03/05/12 09:01, Rainer Orth wrote:
This is where I need explicit approval and/or guidance:
* There are some fixincludes hacks that from their names seem to be
osf-specific, but are not restricted to alpha*-dec-osf*. Bruce,
what's the best way to handle those? Disable them e.g. with a mach
clause like unused-alpha*-dec-osf* and see if anything else breaks?
I think the right way is to require that all ports have a maintenance
person build the thing at least once a year for all supported platforms.
For such maintenance builds, I can trivially emit a list of hacks that
got triggered during the build. Any hacks that don't show up in the
list for a couple of years get marked as "obsolete" and trigger a build
warning. If nobody complains about the warning, then its gone.
Shouldn't take more than 3 or 4 years of disuse to get rid of the cruft. :)
How's that for an approach?
Cheers - Bruce