This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Don't use -Wno-error=undef
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Andreas Schwab <schwab at linux-m68k dot org>
- Cc: <libc-alpha at sourceware dot org>
- Date: Tue, 18 Aug 2015 17:03:50 +0000
- Subject: Re: Don't use -Wno-error=undef
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1508181621220 dot 17603 at digraph dot polyomino dot org dot uk> <87d1yk7cx1 dot fsf at igel dot home>
On Tue, 18 Aug 2015, Andreas Schwab wrote:
> Joseph Myers <joseph@codesourcery.com> writes:
>
> > Tested for x86_64 and x86. If people see build or test errors
> > resulting from this on other architectures, they should fix those as
> > usual.
>
> That's not how things should work.
It is how things work for anything except where the changes to each
architecture are essentially mechanical and can be identified and done
blindly (e.g. making the same change to all versions of a header). It's
something we have architecture maintainers for - testing and fixing issues
for their architectures where it's not clear from source tree inspection
exactly what architecture-specific changes might turn out to be needed.
In this case, architecture maintainers have been given 17 months (since
commit 498a22333b835a598ccaed4656e97a0ec3573665) to get their
architectures clean for -Wundef issues before such issues start causing
errors.
(In this case any architecture-specific changes are likely to be
mechanical - but they can't be *identified* blindly.)
If we had a system for submitting patches to a buildbot that would then
build them on all architectures and report failures, higher standards of
avoiding build breakage could be applied to such patches (changes
requiring architecture expertise, such as for the cancellation changes,
would still need to be left to architecture maintainers). But we don't
have such a system, and very few architectures are covered at all in the
buildbot we do have.
--
Joseph S. Myers
joseph@codesourcery.com