On Mon, Jul 29, 2019 at 11:23 PM Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote: > > Quoting Masahiro Yamada (2019-07-29 03:02:40) > > > > Thanks for catching this. > > > > I wonder if we could fix this issue > > by one-liner, like this: > > > > > > diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include > > index 8a5c4d645eb1..4bbf4fc163a2 100644 > > --- a/scripts/Kconfig.include > > +++ b/scripts/Kconfig.include > > @@ -25,7 +25,7 @@ failure = $(if-success,$(1),n,y) > > > > # $(cc-option,<flag>) > > # Return y if the compiler supports <flag>, n otherwise > > -cc-option = $(success,$(CC) -Werror $(1) -E -x c /dev/null -o /dev/null) > > +cc-option = $(success,$(CC) -Werror $(CLANG_FLAGS) $(1) -E -x c > > /dev/null -o /dev/null) > > > > # $(ld-option,<flag>) > > # Return y if the linker supports <flag>, n otherwise > > > > > > > > This propagates not only -Werror=unknown-warning-option > > but also other clang flags to Kconfig. > > > > > > Currently, we do not pass the target triplet to Kconfig. > > This means, cc-option in Kconfig evaluates the given flags > > against host-arch instead of target-arch. > > The compiler flags are mostly independent of the architecture, > > and this is not a big deal, I think. > > But, maybe, would it make more sense to pass the other > > basic clang flags as well? > > > > Yes that also works and I had that earlier. I wanted to mirror what was > done in scripts/Kbuild.include where there's a CC_OPTION_CFLAGS > variable. I'm happy either way, so it's up to you. > Can you post v3 with $(CLANG_FLAGS) ? Thanks. -- Best Regards Masahiro Yamada
