bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Idea: Allow $(name ...) as an abbrevation of $(call name ....)


From: Masahiro Yamada
Subject: Re: Idea: Allow $(name ...) as an abbrevation of $(call name ....)
Date: Tue, 11 Jun 2019 14:09:42 +0900

On Mon, Jun 10, 2019 at 12:46 PM David A. Wheeler <address@hidden> wrote:
>
> On Mon, 10 Jun 2019 11:56:04 +0900, Masahiro Yamada <address@hidden> wrote:
> > It is a design.
>
> Sure, but we can add to it.
>
> > In summary, there is slight difference between
> > a variable and a user-defined function.
> > Omitting 'call' makes obscure the difference between them.
>
> I don't think it obscures the difference at all.
> The presence of parameters makes the difference quite obvious.
>
> Let's use the examples from:
> https://www.gnu.org/software/make/manual/html_node/Call-Function.html
>
> # Current:
> foo = $(call reverse,a,b)
> # Proposed alternative:
> foo = $(reverse a,b)
>
> # Current:
> LS := $(call pathsearch,ls)
> # Proposed alternative:
> LS := $(pathsearch ls)
>
>
> # Current:
> o = $(call map,origin,o map MAKE)
> # Proposed alternative:
> o = $(map origin,o map MAKE)
>
>
> There is *one* case I can agree would be obscure.
> That would be a space with NO parameters. E.g., $(hello ).
> That's more likely to be an error than a function call.
> So perhaps the short form should require something other than a ")"
> right after the name's whitespace; if you want to call a function
> with no parameters (why?) you'd be required to use $(call NAME).
> I'd be happy with that limitation on the syntactic sugar.
>


Shameless plugin:


I am just interested in this topic because
I implemented a similar language for Kconfig some time ago.
(Kconfig is a configuration system for Linux Kernel).


BTW, is the 'call' the only regret in the design ?


I wish the function call were:

 $(func,arg1,arg2,arg3)

instead of

 $(func arg1,arg2,arg3)


In Make, the function name and the first argument are separated
by at least one whitespace.
Then, all leading whitespaces are trimmed from the first argument.

This means, we cannot pass spaces to the first argument
(at least in a straightforward way).

$(info hello)
 and
$(info       hello)
print the same result.


To print an indented message,
we need some trick.

empty :=
space := $(empty) $(empty)
$(info $(space)$(space)hello)



While the macro language for Kconfig was highly inspired by Make,
I changed the syntax of the function call.


[1] Omit $(call ...) for user-defined function.
   Built-in functions and user-defined functions
   are called in the same way:

    $(func,arg1,arg2,arg3)


[2] Use a comma for every separator, and do not trim spaces at all.
    I wanted to avoid gotchas when we pass spaces to the first argument.



The real example in the Linux kernel code is like this:
https://github.com/torvalds/linux/blob/v5.2-rc4/arch/Kconfig#L479

'cc-option' is a user-defined function that
expands into 'y' when the given compiler flag is supported.


Recursive variables and user-defined functions
are defined by using '=',
and they are expanded recursively.
This is the same concept as Make.

https://github.com/torvalds/linux/blob/v5.2-rc4/scripts/Kconfig.include#L28
https://github.com/torvalds/linux/blob/v5.2-rc4/scripts/Kconfig.include#L20
https://github.com/torvalds/linux/blob/v5.2-rc4/scripts/Kconfig.include#L16

'shell' is a built-in function.
Only the difference is that it uses a comma instead of a space.


So, in Kconfig,
there is no distinction between builtin and user-defined,
no distinction between variable and function.
('variable' is a subset of 'function' that happens to have zero argument)

So, I added 'recursive reference' check only when the number of
arguments is zero:
https://github.com/torvalds/linux/blob/v5.2-rc4/scripts/kconfig/preprocess.c#L260


That simplification was possible since it was a new language.

I would not say Make should be changed in the same way.
Makefiles are written in the current way, and at least works.


We can continue 'in hindsight' talks if we like.

For example, we have two different syntax for similar goal.
The recently-supported grouped target:

   foo bar &: pre1 pre2

and the pattern rule with multiple targets

   %foo %bar : pre1 pre2


If we drop the compatibility like Python 3,
We could fix our regrets ...


--
Best Regards

Masahiro Yamada



reply via email to

[Prev in Thread] Current Thread [Next in Thread]