| Message ID | 20170721215657.81631-1-mka@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
El Fri, Jul 21, 2017 at 02:56:56PM -0700 Matthias Kaehlcke ha dit: > The macro cc-option receives two parameters (the second may be empty). It > returns the first parameter if it is a valid compiler option, otherwise > the second one. It is not evaluated if the second parameter is a valid > compiler option. This seems to be fine in virtually all cases, however > there are scenarios where the second paramater needs to be evaluated too, > and an empty value (or a third option) should be returned if it is not > valid. > > The macro cc-option-3 receives three parameters and returns parameter 1 > or 2 (in this order) if one of them is found to be a valid compiler > option, and otherwise paramater 3. The macro __cc-option-3 works > analogously. Any comment on this? Thanks Matthias > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > --- > scripts/Kbuild.include | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include > index dd8e2dde0b34..dc83635f2317 100644 > --- a/scripts/Kbuild.include > +++ b/scripts/Kbuild.include > @@ -113,6 +113,11 @@ as-instr = $(call try-run,\ > __cc-option = $(call try-run,\ > $(1) -Werror $(2) $(3) -c -x c /dev/null -o "$$TMP",$(3),$(4)) > > +# __cc-option-3 > +# Usage: MY_CFLAGS += $(call __cc-option-3,$(CC),$(MY_CFLAGS),\ > +# -mpreferred-stack-boundary=2,-mstack-alignment=4,) > +__cc-option-3 = $(call __cc-option,$(1),$(2),$(3),$(call __cc-option,$(1),$(2),$(4),$(5))) > + > # Do not attempt to build with gcc plugins during cc-option tests. > # (And this uses delayed resolution so the flags will be up to date.) > CC_OPTION_CFLAGS = $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS)) > @@ -123,6 +128,10 @@ CC_OPTION_CFLAGS = $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS)) > cc-option = $(call __cc-option, $(CC),\ > $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS),$(1),$(2)) > > +# cc-option-3 > +# Usage: cflags-y += $(call cc-option-3,-mpreferred-stack-boundary=3,-mstack-alignment=8,) > +cc-option-3 = $(call cc-option,$(1),$(call cc-option,$(2),$(3))) > + > # hostcc-option > # Usage: cflags-y += $(call hostcc-option,-march=winchip-c6,-march=i586) > hostcc-option = $(call __cc-option, $(HOSTCC),\ -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Matthias, Sorry for my late reply. 2017-08-03 1:46 GMT+09:00 Matthias Kaehlcke <mka@chromium.org>: > El Fri, Jul 21, 2017 at 02:56:56PM -0700 Matthias Kaehlcke ha dit: > >> The macro cc-option receives two parameters (the second may be empty). It >> returns the first parameter if it is a valid compiler option, otherwise >> the second one. It is not evaluated if the second parameter is a valid >> compiler option. This seems to be fine in virtually all cases, however >> there are scenarios where the second paramater needs to be evaluated too, >> and an empty value (or a third option) should be returned if it is not >> valid. >> >> The macro cc-option-3 receives three parameters and returns parameter 1 >> or 2 (in this order) if one of them is found to be a valid compiler >> option, and otherwise paramater 3. The macro __cc-option-3 works >> analogously. > > Any comment on this? > > Thanks > > Matthias > >> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> >> --- >> scripts/Kbuild.include | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include >> index dd8e2dde0b34..dc83635f2317 100644 >> --- a/scripts/Kbuild.include >> +++ b/scripts/Kbuild.include >> @@ -113,6 +113,11 @@ as-instr = $(call try-run,\ >> __cc-option = $(call try-run,\ >> $(1) -Werror $(2) $(3) -c -x c /dev/null -o "$$TMP",$(3),$(4)) >> >> +# __cc-option-3 >> +# Usage: MY_CFLAGS += $(call __cc-option-3,$(CC),$(MY_CFLAGS),\ >> +# -mpreferred-stack-boundary=2,-mstack-alignment=4,) >> +__cc-option-3 = $(call __cc-option,$(1),$(2),$(3),$(call __cc-option,$(1),$(2),$(4),$(5))) >> + >> # Do not attempt to build with gcc plugins during cc-option tests. >> # (And this uses delayed resolution so the flags will be up to date.) >> CC_OPTION_CFLAGS = $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS)) >> @@ -123,6 +128,10 @@ CC_OPTION_CFLAGS = $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS)) >> cc-option = $(call __cc-option, $(CC),\ >> $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS),$(1),$(2)) >> >> +# cc-option-3 >> +# Usage: cflags-y += $(call cc-option-3,-mpreferred-stack-boundary=3,-mstack-alignment=8,) >> +cc-option-3 = $(call cc-option,$(1),$(call cc-option,$(2),$(3))) I do not like this macro much for the following reasons: [1] I guess your motivation is to evaluate the second option, not receive the third option. If this is the demand, I thought it might be nicer to change cc-option to always evaluate the second option. (I do no have a good idea for the implementation.) [2] cc-option-3 = $(call cc-option,$(1),$(call cc-option,$(2),$(3))) evaluates the inner $(call cc-option,) first. This works a bit differently from our expectation. For example, let's consider the following case. $(call cc-option-3,-Oz,-Os,-O2) I think we generally expect -Oz, -Os are tested in this order. (If -Oz is supported by the compiler, the test for -Os will be skipped.) In fact, cc-option-3 tests -Os, -Oz in this order because inner cc-option is evaluated before the outer one. The test for -Os may or may not be necessary. I do not have a good idea to improve this...
Hi Masahiro, El Mon, Aug 07, 2017 at 10:01:41AM +0900 Masahiro Yamada ha dit: > Hi Matthias, > > Sorry for my late reply. > > 2017-08-03 1:46 GMT+09:00 Matthias Kaehlcke <mka@chromium.org>: > > El Fri, Jul 21, 2017 at 02:56:56PM -0700 Matthias Kaehlcke ha dit: > > > >> The macro cc-option receives two parameters (the second may be empty). It > >> returns the first parameter if it is a valid compiler option, otherwise > >> the second one. It is not evaluated if the second parameter is a valid > >> compiler option. This seems to be fine in virtually all cases, however > >> there are scenarios where the second paramater needs to be evaluated too, > >> and an empty value (or a third option) should be returned if it is not > >> valid. > >> > >> The macro cc-option-3 receives three parameters and returns parameter 1 > >> or 2 (in this order) if one of them is found to be a valid compiler > >> option, and otherwise paramater 3. The macro __cc-option-3 works > >> analogously. > > > > Any comment on this? > > > > Thanks > > > > Matthias > > > >> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > >> --- > >> scripts/Kbuild.include | 9 +++++++++ > >> 1 file changed, 9 insertions(+) > >> > >> diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include > >> index dd8e2dde0b34..dc83635f2317 100644 > >> --- a/scripts/Kbuild.include > >> +++ b/scripts/Kbuild.include > >> @@ -113,6 +113,11 @@ as-instr = $(call try-run,\ > >> __cc-option = $(call try-run,\ > >> $(1) -Werror $(2) $(3) -c -x c /dev/null -o "$$TMP",$(3),$(4)) > >> > >> +# __cc-option-3 > >> +# Usage: MY_CFLAGS += $(call __cc-option-3,$(CC),$(MY_CFLAGS),\ > >> +# -mpreferred-stack-boundary=2,-mstack-alignment=4,) > >> +__cc-option-3 = $(call __cc-option,$(1),$(2),$(3),$(call __cc-option,$(1),$(2),$(4),$(5))) > >> + > >> # Do not attempt to build with gcc plugins during cc-option tests. > >> # (And this uses delayed resolution so the flags will be up to date.) > >> CC_OPTION_CFLAGS = $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS)) > >> @@ -123,6 +128,10 @@ CC_OPTION_CFLAGS = $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS)) > >> cc-option = $(call __cc-option, $(CC),\ > >> $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS),$(1),$(2)) > >> > >> +# cc-option-3 > >> +# Usage: cflags-y += $(call cc-option-3,-mpreferred-stack-boundary=3,-mstack-alignment=8,) > >> +cc-option-3 = $(call cc-option,$(1),$(call cc-option,$(2),$(3))) > > > I do not like this macro much for the following reasons: > > > [1] > I guess your motivation is to evaluate the second option, > not receive the third option. In this case yes, a future use case could be to support another compiler with different option names, but I suppose we can focus on the present for now. > If this is the demand, I thought it might be nicer to > change cc-option to always evaluate the second option. I considered that, but was reluctant to change current behavior, though in practice it shouldn't make a difference. > (I do no have a good idea for the implementation.) One option could be a variant of the try-run macro, that receives the 'base command' as first parameter: try-run-opt = $(shell set -e; \ TMP="$(TMPOUT).$$$$.tmp"; \ TMPO="$(TMPOUT).$$$$.o"; \ if ($(1) $(2)) >/dev/null 2>&1; \ then echo "$(2)"; \ elif [ -n "${3}" ] && ($(1) $(3)) >/dev/null 2>&1; \ then echo "$(3)"; \ else echo ""; \ fi; \ rm -f "$$TMP" "$$TMPO") __cc-option = $(call try-run-opt,\ $(1) -Werror $(2) -c -x c /dev/null -o "$$TMP",$(3),$(4)) try-run-opt assumes that is is valid to append an option to the end of the base command. For consistency we'd probably want to adapt other suitable xx-option macros as well. Does this look reasonable to you? > cc-option-3 = $(call cc-option,$(1),$(call cc-option,$(2),$(3))) > > evaluates the inner $(call cc-option,) first. > > This works a bit differently from our expectation. > > > For example, let's consider the following case. > > $(call cc-option-3,-Oz,-Os,-O2) > > > I think we generally expect -Oz, -Os are tested in this order. > (If -Oz is supported by the compiler, the test for -Os will be skipped.) > > > In fact, cc-option-3 tests -Os, -Oz in this order > because inner cc-option is evaluated before the outer one. > The test for -Os may or may not be necessary. I agree, running the check for the alternative options always is not desirable. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include index dd8e2dde0b34..dc83635f2317 100644 --- a/scripts/Kbuild.include +++ b/scripts/Kbuild.include @@ -113,6 +113,11 @@ as-instr = $(call try-run,\ __cc-option = $(call try-run,\ $(1) -Werror $(2) $(3) -c -x c /dev/null -o "$$TMP",$(3),$(4)) +# __cc-option-3 +# Usage: MY_CFLAGS += $(call __cc-option-3,$(CC),$(MY_CFLAGS),\ +# -mpreferred-stack-boundary=2,-mstack-alignment=4,) +__cc-option-3 = $(call __cc-option,$(1),$(2),$(3),$(call __cc-option,$(1),$(2),$(4),$(5))) + # Do not attempt to build with gcc plugins during cc-option tests. # (And this uses delayed resolution so the flags will be up to date.) CC_OPTION_CFLAGS = $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS)) @@ -123,6 +128,10 @@ CC_OPTION_CFLAGS = $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS)) cc-option = $(call __cc-option, $(CC),\ $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS),$(1),$(2)) +# cc-option-3 +# Usage: cflags-y += $(call cc-option-3,-mpreferred-stack-boundary=3,-mstack-alignment=8,) +cc-option-3 = $(call cc-option,$(1),$(call cc-option,$(2),$(3))) + # hostcc-option # Usage: cflags-y += $(call hostcc-option,-march=winchip-c6,-march=i586) hostcc-option = $(call __cc-option, $(HOSTCC),\
The macro cc-option receives two parameters (the second may be empty). It returns the first parameter if it is a valid compiler option, otherwise the second one. It is not evaluated if the second parameter is a valid compiler option. This seems to be fine in virtually all cases, however there are scenarios where the second paramater needs to be evaluated too, and an empty value (or a third option) should be returned if it is not valid. The macro cc-option-3 receives three parameters and returns parameter 1 or 2 (in this order) if one of them is found to be a valid compiler option, and otherwise paramater 3. The macro __cc-option-3 works analogously. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> --- scripts/Kbuild.include | 9 +++++++++ 1 file changed, 9 insertions(+)