Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.01.17 at 15:38, <ian.jackson@xxxxxxxxxxxxx> wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict 
> -Werror checking"):
>> Alistair Francis <alistair.francis@xxxxxxxxxx> 12/22/16 8:14 PM >>>
>> >Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
>> >as I still see warnings/errors when building: tools/kconfig/conf.c.
>> 
>> Well, it's quite obvious that the same set of options (and hence overrides)
>> can't possibly fit both the build of target binaries and the build of build
>> helper tools (i.e. build host binaries).
> 
> I think that the example of `-Wno-error' shows that this is, in fact,
> false.  There are some overrides that, if desirable, apply equally
> everywhere.

I agree, but I don't think this is relevant here: How does one
easily(!) know that APPEND_CFLAGS affects both host and
target binaries? Just like there is HOSTCC and HOSTCFLAGS,
there should be (e.g.) APPEND_HOSTCFLAGS. What if
$(HOSTCC) doesn't even understand -Wno-error (or any other
option put into such a shared variable)?

> -Wno-error is a good example because it is mostly needed when a new
> compiler throws up new warnings for existing code.  Admittedly,
> -Wno-error may not be the best response, but it is often the most
> expedient, and we shouldn't make it unnecessarily hard for
> downstreams to support it.
> 
> For now I think the proposed approach, to make kconf build honour
> APPEND_CFLAGS, is good.  Do you agree, Jan ?
> 
> If someone wants to introduce HYPERVISOR_APPEND_CFLAGS and
> TOOLS_APPEND_CFLAGS, I don't object, but that should be a separate
> project.

As per above, I disagree. We shouldn't help people making
mistakes by lumping together two disjoint sets of flags.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel