Re: [xen-4.0-testing test] 7147: regressions - FAIL

[Keir Fraser <keir@xen.org>]

On 23/05/2011 16:49, "Keir Fraser" <keir@xen.org> wrote:

> On 23/05/2011 16:40, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> 
>> Keir Fraser writes ("Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions
>> - FAIL"):
>>> Here's a nice short one that seems to work for me. It does rely on the
>>> compiler emitting the word 'unrecognized' iff the option under test is
>>> unrecognised. I strongly suspect this is a safe bet.
>> 
>> Sadly, some mad people run with LC_MESSAGES set to something other
>> than C which produces native-language error messages even from gcc.
> 
> Well LC_ALL=C is easy to add.

Here is an updated version taking into account comments on- and off-list. To
be clear, its main advantages are brevity and that it strips out even
options that only cause harmless (but potentially annoying/crufting)
conditional compile warnings. Its main *disadvantage* is that it scrapes the
compiler's stdout/stderr, albeit for the option-under-test itself which
frankly should be a very safe bet.

 -- Keir

diff -r 0f670f5146c8 Config.mk
--- a/Config.mk Sat May 21 07:55:46 2011 +0100
+++ b/Config.mk Mon May 23 17:12:55 2011 +0100
@@ -71,9 +71,19 @@ PYTHON_PREFIX_ARG ?= --prefix="$(PREFIX)
 #  https://bugs.launchpad.net/ubuntu/+bug/362570
 
 # cc-option: Check if compiler supports first option, else fall back to
second.
+#
+# This is complicated by the fact that unrecognised -Wno-* options:
+#   (a) are ignored unless the compilation emits a warning; and
+#   (b) even then produce a warning rather than an error
+# To handle this we do a test compile, passing the option-under-test, on a
code
+# fragment that will always produce a warning (integer assigned to
pointer).
+# We then grep for the option-under-test in the compiler's output, the
presence
+# of which would indicate an "unrecognized command-line option"
warning/error.
+#
 # Usage: cflags-y += $(call cc-option,$(CC),-march=winchip-c6,-march=i586)
-cc-option = $(shell if test -z "`$(1) $(2) -S -o /dev/null -xc \
-              /dev/null 2>&1`"; then echo "$(2)"; else echo "$(3)"; fi ;)
+cc-option = $(shell if test -z "`echo 'void*p=1;' | \
+              $(1) $(2) -S -o /dev/null -xc - 2>&1 | grep -- $(2)`"; \
+              then echo "$(2)"; else echo "$(3)"; fi ;)
 


>>> Unfortunately I can't
>>> see any way around grepping the output, since otherwise we can't distinguish
>>> the integer-assignment-to-pointer warning from the unrecognised-option
>>> warning.
>> 
>> We don't need to distinguish them.  We just need to know whether
>> passing the option works or not.  That's what my patch does.
> 
> Ahhh... Is this because of a emitted-as-an-error-not-a-warning bug in Debian
> gcc, on top of the more general lazily-detected-unrecognised-Wno-option
> behaviour?
> 
> Well, tbh I'd rather get rid of unsupported -Wno- options in general, not
> just where they are erroneously emitted as errors. Otherwise it will confuse
> everyone that each time they get a compile warning they also get extra bogus
> unrecognised option messages. That would be pretty crappy.
> 
>  -- Keir
> 
>> Ian.
> 
>