This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Remove obsolete Tru64 UNIX V5.1B fixinclude support
- From: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- To: Bruce Korb <bkorb at gnu dot org>
- 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 19:03:52 +0100
- Subject: Re: Remove obsolete Tru64 UNIX V5.1B fixinclude support
- References: <yddsjhnrngz.fsf@manam.CeBiTec.Uni-Bielefeld.DE> <4F54F7E5.60007@gnu.org>
Bruce Korb <bkorb@gnu.org> writes:
> 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?
Sounds like a good approach, since it helps even for hacks with mach
clauses that are matched on supported target version, e.g. a
*-*-solaris2* hack that only applies to Solaris 2.5 and is thus
irrelevant nowadays.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University