lkml.org 
[lkml]   [2018]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 08/23] kconfig: add 'macro' keyword to support user-defined function
    On Sat, 17 Feb 2018, Ulf Magnusson wrote:

    > On Sat, Feb 17, 2018 at 3:30 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
    > > 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
    >
    > I still don't quite get the semantics here. How would the behavior
    > change if the type was changed to say string or int in some or all of
    > the lines?

    I admit this wouldn't make sense to have multiple different types. In
    this example, the bool keyword acts as syntactic sugar more than
    anything else.

    > Since the current model is to evaluate $() while the Kconfig files are
    > being parsed, would this require evaluating Kconfig expressions during
    > parsing? There is a relatively clean and (somewhat) easy to understand
    > parsing/evaluation separation at the moment, which I like.

    Agreed. Let's forget about the conditionals then.


    Nicolas

    \
     
     \ /
      Last update: 2018-02-17 05:45    [W:3.124 / U:1.120 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site