[Top][All Lists]

[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: Mon, 10 Jun 2019 11:56:04 +0900


On Mon, Jun 10, 2019 at 10:55 AM Paul Smith <address@hidden> wrote:
> On Sun, 2019-06-09 at 18:53 -0400, David A. Wheeler wrote:
> > There's also no need for it. If "name" is followed by whitespace it *cannot*
> > be a POSIX variable reference, because POSIX doesn't allow that.
> >
> > Solution:
> > Just allow $(name ...), where 1+ whitespace follows name, to be considered
> > the same as $(call name...).
> >
> > I would allow $(no-parameters ), with a space after the name and no 
> > parameters,
> > though in practice I don't think that's very useful.  If you really wanted 
> > that (why?),
> > I think $(call no-parameters) would be clearer as a call, and 
> > $(no-parameters)
> > seems more useful :-).
> It's true that POSIX doesn't allow this, but actually it was legal in
> make for a long time.
> This suggestion is something I've thought of doing myself, and I've
> been working towards it for a while now, by first removing support for
> variable names containing spaces.
> Probably it's OK to finally implement this, at this point.

I do not think Make's $(call ...) is too ugly.
It is a design.

If we had started without 'call' from the beginning of the design,
it would have made sense.

Makefiles have been written with 'call', so it is a bit
questionable to add a new syntax-sugar now.

This is my thought about 'call'.

'call' is a built-in function that is used
to expand a user-defined function.

The difference between a recursively-expanded variable
and a user-defined function is subtle.

Theoretically, the difference is the number of arguments.

Variables have definitely zero argument.
User-defined functions have zero or more arguments.

Only the difference I noticed is
the circular reference check.

If the recursively-expanded variable references itself,
the expansion would absolutely continue forever.
So, GNU Make reports error.

-------test code------
a = $a

        echo $a
-------test code end----

$ make
Makefile:1: *** Recursive variable 'a' references itself (eventually).  Stop.

On the other hand, a function that calls itself is
a common programming technique.

I do not see many cases where recursive function call
is useful in Makefile, but we can create such examples.

For example, in the following sample,
a user-defined function 'reverse' calls itself.

This will finish.

-------test code2------
# reverse the given argument
reverse = $(if $1,$(call reverse,$(wordlist 2,$(words $1),$1))$(firstword $1) )

        @echo $(call reverse,1 2 3 4 5)
--------test code2 END------

$ make
5 4 3 2 1

Of course, you can create a recursive function
call that never ends.
This is a fault of those who wrote the Makefile.

-------test code3--------
a = $(call a)

        @echo $a
-------test code3 END--------

$ make

... this continues running forever.
GNU Make does not detect this
since it is legitimate for a function calls itself.

In summary, there is slight difference between
a variable and a user-defined function.
Omitting 'call' makes obscure the difference between them.

reply via email to

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