On Sat, 17 Feb 2018, Ulf Magnusson wrote: > On Fri, Feb 16, 2018 at 02:49:31PM -0500, Nicolas Pitre wrote: > > On Sat, 17 Feb 2018, Masahiro Yamada wrote: > > > > > Now, we got a basic ability to test compiler capability in Kconfig. > > > > > > config CC_HAS_STACKPROTECTOR > > > bool > > > default $(shell $CC -Werror -fstack-protector -c -x c /dev/null -o /dev/null) > > > > > > This works, but it is ugly to repeat this long boilerplate. > > > > > > We want to describe like this: > > > > > > config CC_HAS_STACKPROTECTOR > > > bool > > > default $(cc-option -fstack-protector) > > > > > > It is straight-forward to implement a new function, but I do not like > > > to hard-code specialized functions like this. Hence, here is another > > > feature to add functions from Kconfig files. > > > > > > A user-defined function can be defined as a string type symbol with > > > a special keyword 'macro'. It can be referenced in the same way as > > > built-in functions. This feature was also inspired by Makefile where > > > user-defined functions are referenced by $(call func-name, args...), > > > but I omitted the 'call' to makes it shorter. > > > > > > The macro definition can contain $(1), $(2), ... which will be replaced > > > with arguments from the caller. > > > > > > Example code: > > > > > > config cc-option > > > string > > > macro $(shell $CC -Werror $(1) -c -x c /dev/null -o /dev/null) > > > > I think this syntax for defining a macro shouldn't start with the > > "config" keyword, unless you want it to be part of the config symbol > > space and land it in .config. And typing it as a "string" while it > > actually returns y/n (hence a bool) is also strange. > > > > What about this instead: > > > > macro cc-option > > bool $(shell $CC -Werror $(1) -c -x c /dev/null -o /dev/null) > > > > This makes it easier to extend as well if need be. > > > > > > Nicolas > > I haven't gone over the patchset in detail yet and might be missing > something here, but if this is just meant to be a textual shorthand, > then why give it a type at all? It is meant to be like a user-defined function. > Do you think a simpler syntax like this would make sense? > > macro cc-option "$(shell $CC -Werror $(1) -c -x c /dev/null -o /dev/null)" > > That's the most general version, where you could use it for other stuff > besides $(shell ...) as well, just to keep parity. This is not extendable. Let's imagine that you might want to implement some kind of conditionals some day e.g.: macro complex_test bool $(shell foo) if LOCKDEP_SUPPORT bool y if DEBUG_DRIVER bool n There is no real advantage to simplify the macro definition to its simplest expression, unlike its actual usage. > Are there any cases where something more advanced than that might be > warranted (e.g., macros that expand to complete expressions)? Maybe not now, but there is no need to close the door on the possibility either. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
