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

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

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

David A. Wheeler
I propose allowing $(name ...) as an abbrevation of $(call name ....).

Problem:
You currently have to use the somewhat ugly construct $(call name...)
to call something.  If you use functions a lot that's a little ugly.

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 :-).

Okay, that's my final of 4 ideas (well, at least for the moment :-) ).

--- David A. Wheeler

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

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

Paul Smith-20
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.


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

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

Masahiro Yamada-2
Hi.

On Mon, Jun 10, 2019 at 10:55 AM Paul Smith <[hidden email]> 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

all:
        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) )

all:
        @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)

all:
        @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.

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

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

David A. Wheeler
On Mon, 10 Jun 2019 11:56:04 +0900, Masahiro Yamada <[hidden email]> 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.

--- David A. Wheeler
_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

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

Tim Murphy-4
If you can't make first-class functions that are the equal of $(filter) or $(subst) or whatever, or indeed replace them, then it seems like a bit of a fudge for the sake of 4 characters. 

I think one could end up having huge discussions about this to a pretty limited benefit and miss spending the time on some of your other proposals which get around really significant problems.

Regards,

Tim

On Mon, 10 Jun 2019 at 04:46, David A. Wheeler <[hidden email]> wrote:
On Mon, 10 Jun 2019 11:56:04 +0900, Masahiro Yamada <[hidden email]> 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.

--- David A. Wheeler
_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

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

David A. Wheeler
On Mon, 10 Jun 2019 22:46:23 +0100, Tim Murphy <[hidden email]> wrote:
> If you can't make first-class functions that are the equal of $(filter) or
> $(subst) or whatever, or indeed replace them, then it seems like a bit of a
> fudge for the sake of 4 characters.

You can make functions that do the work of $(filter) or $(subst)
and look the same if the ugly "call" prefix wasn't required.  So I don't understand
what you mean by the precondition.

Almost all other languages try to *eliminate* distinctions between built-ins
and user-defined functions.  This makes it easy, for example, to transition
from a user-defined function to a built-in function if the user-defined function
becomes a built-in.  GNU make is an oddity in that regard.
The "call" creates a completely unnecessary distinction between
built-in functions and user-defined functions.

It's not 4 characters, it's 5 characters including space, and it's not once per Makefile.
These characters are wasted on *EVERY* function invocation.
If function invocations are rare that's no big deal.
If you invoke functions often then that starts to get annoying.
I have a makefile where at least one function is invoked in practically every rule,
so they're starting to really add up.

> I think one could end up having huge discussions about this to a pretty
> limited benefit and miss spending the time on some of your other proposals
> which get around really significant problems.

Thanks!

Unfortunately I have to wait for my company to work through the FSF contribution paperwork
before I can write/contribute code.
We've done it before, so hopefully it won't take *too* long.

But that gives me time to discuss on this mailing list various ideas
and hopefully refine them.
And of course, if someone *else* implements them that'd be even
better from my point of view :-).

--- David A. Wheeler
_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

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

Masahiro Yamada
In reply to this post by David A. Wheeler
On Mon, Jun 10, 2019 at 12:46 PM David A. Wheeler <[hidden email]> wrote:

>
> On Mon, 10 Jun 2019 11:56:04 +0900, Masahiro Yamada <[hidden email]> 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

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

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

David A. Wheeler
On Tue, 11 Jun 2019 14:09:42 +0900, Masahiro Yamada <[hidden email]> wrote:
> If we drop the compatibility like Python 3,
> We could fix our regrets ...

The Python3 transition was horrific,
and is a textbook case of how to *not* handle a transition.
It's not that Python3 is bad (I use it), but its transition
was handled very badly.

Backwards compatibility matters *greatly*.

> 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).

I didn't realize Kconfig had these features.
Thanks for noting it, we should certainly try to learn from it.

> 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).
...
> [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.
...
> 'shell' is a built-in function.
> Only the difference is that it uses a comma instead of a space.

Interesting.  I see the argument for it!

I have the opposite problem: I usually do *NOT*
want to pass leading & trailing spaces in my arguments,
and so I keep having to $(strip ...) my arguments in functions.
Make's insistence on including spaces in each argument
also makes it difficult to break up long lines;
I can't easily have a "parameter on each line" like many languages
because the whitespace will be in the parameter.
That suggests that maybe a variant would be helpful
to automatically strip the parameters before calling.

So thinking out loud, I can see three options for
adding user-defined direct calls:
1. $(name arg1,arg2,...): Equivalent to
   $(call name,$(strip-leading-space arg1),arg2,...).
   This is my original proposal.
   The advantage of this syntax is that it's consistent with existing
   function calls, which many people know.
   Oddly, there's no obvious Make $(....) function built-in that does
   strip-leading-space (maybe there should be).
2. $(name,arg1,arg2,...): Equivalent to $(call name,arg1,arg2,...).
   This retains all leading/trailing whitespace and is compatible
    with Kconfig syntax (slightly simplifying transfers between them).
   "name" can be user-defined or a built-in.
3. $(name;arg1;arg2;...): Equivalent to
   $(call name,$(strip arg1),$(strip arg2),...).
   This would make it easy to add space after the parameter separator
   (like people do in many other languages) and break lines
   between parameters when the parameter set is long.
   It would also simplify passing arguments containing commas.

I would be happy if all 3 were implemented, really; they all have
their own trade-offs.  At least #1 or #2 should be implemented.

--- David A. Wheeler
_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

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

Tim Murphy-4
builtin functions can check their arguments to some extent. Interesting to wonder if user defined ones can.
we don't even have $(equals) or a way to know the number of arguments that were supplied or any mathematical operations with which to compare. So when something is called wongly it charges on to the end, evaluating blindly to who knows what and we can spend hours trying to tease out the cause of a missing compiler option .... but.....we are focused on the saving of a tiny bit of typing.

.....

Regards,

Tim

On Tue, 11 Jun 2019 at 14:09, David A. Wheeler <[hidden email]> wrote:
On Tue, 11 Jun 2019 14:09:42 +0900, Masahiro Yamada <[hidden email]> wrote:
> If we drop the compatibility like Python 3,
> We could fix our regrets ...

The Python3 transition was horrific,
and is a textbook case of how to *not* handle a transition.
It's not that Python3 is bad (I use it), but its transition
was handled very badly.

Backwards compatibility matters *greatly*.

> 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).

I didn't realize Kconfig had these features.
Thanks for noting it, we should certainly try to learn from it.

> 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).
...
> [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.
...
> 'shell' is a built-in function.
> Only the difference is that it uses a comma instead of a space.

Interesting.  I see the argument for it!

I have the opposite problem: I usually do *NOT*
want to pass leading & trailing spaces in my arguments,
and so I keep having to $(strip ...) my arguments in functions.
Make's insistence on including spaces in each argument
also makes it difficult to break up long lines;
I can't easily have a "parameter on each line" like many languages
because the whitespace will be in the parameter.
That suggests that maybe a variant would be helpful
to automatically strip the parameters before calling.

So thinking out loud, I can see three options for
adding user-defined direct calls:
1. $(name arg1,arg2,...): Equivalent to
   $(call name,$(strip-leading-space arg1),arg2,...).
   This is my original proposal.
   The advantage of this syntax is that it's consistent with existing
   function calls, which many people know.
   Oddly, there's no obvious Make $(....) function built-in that does
   strip-leading-space (maybe there should be).
2. $(name,arg1,arg2,...): Equivalent to $(call name,arg1,arg2,...).
   This retains all leading/trailing whitespace and is compatible
    with Kconfig syntax (slightly simplifying transfers between them).
   "name" can be user-defined or a built-in.
3. $(name;arg1;arg2;...): Equivalent to
   $(call name,$(strip arg1),$(strip arg2),...).
   This would make it easy to add space after the parameter separator
   (like people do in many other languages) and break lines
   between parameters when the parameter set is long.
   It would also simplify passing arguments containing commas.

I would be happy if all 3 were implemented, really; they all have
their own trade-offs.  At least #1 or #2 should be implemented.

--- David A. Wheeler
_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

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

David A. Wheeler
On Thu, 13 Jun 2019 18:18:15 +0100, Tim Murphy <[hidden email]> wrote:
> builtin functions can check their arguments to some extent. Interesting to
> wonder if user defined ones can.
> we don't even have $(equals) or a way to know the number of arguments that
> were supplied or any mathematical operations with which to compare. So when
> something is called wongly it charges on to the end, evaluating blindly to
> who knows what and we can spend hours trying to tease out the cause of a
> missing compiler option .... but.....we are focused on the saving of a tiny
> bit of typing.

It's not the typing, it's the reading.  When 20% of the lines makes a user-defined
function call (my situation), simplifying the function call matters.

Equals and math operations can be implemented using $(shell ...).
If you think more are needed, that sounds like a proposal, go ahead and make it.
There's no conflict between this syntax proposal & adding more built-in functions.

--- David A. Wheeler

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

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

Masahiro Yamada
In reply to this post by Tim Murphy-4
On Fri, Jun 14, 2019 at 4:16 AM Tim Murphy <[hidden email]> wrote:
>
> builtin functions can check their arguments to some extent. Interesting to wonder if user defined ones can.
> we don't even have $(equals) or a way to know the number of arguments that were supplied or any mathematical operations with which to compare. So when something is called wongly it charges on to the end, evaluating blindly to who knows what and we can spend hours trying to tease out the cause of a missing compiler option .... but.....we are focused on the saving of a tiny bit of typing.


You can check the number of arguments for user-defined functions if you like.


-------------------(sample code)----------------------
# my-dummy takes 1 or 2 arguments
my-dummy = $(if $(1),,$(error too few arguments))$(if $(3),$(error too
many arguments))echo $(1) $(2)

test1:
        @$(call my-dummy)

test2:
        @$(call my-dummy,hello)

test3:
        @$(call my-dummy,hello,world)

test4:
        @$(call my-dummy,see,you,later)
-------------------(sample code end)----------------------


$ make test1
Makefile:4: *** too few arguments.  Stop.
$ make test2
hello
$ make test3
hello world
$ make test4
Makefile:13: *** too many arguments.  Stop.



If it is tedious to duplicate this check for every user-defined function,
you can macrofy it.


-------------------(sample code 2)----------------------
# Usage: $(eval $(call arg-check,min,max-1))
arg-check = $$(if $$($(1)),,$$(error too few arguments))$$(if
$$($(2)),$$(error too many arguments))

my-dummy = $(eval $(call arg-check,1,3))echo $(1) $(2)
-------------------(sample code 2 end)----------------------


--
Best Regards
Masahiro Yamada

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

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

Masahiro Yamada
In reply to this post by David A. Wheeler
On Fri, Jun 14, 2019 at 2:58 AM David A. Wheeler <[hidden email]> wrote:

>
> On Thu, 13 Jun 2019 18:18:15 +0100, Tim Murphy <[hidden email]> wrote:
> > builtin functions can check their arguments to some extent. Interesting to
> > wonder if user defined ones can.
> > we don't even have $(equals) or a way to know the number of arguments that
> > were supplied or any mathematical operations with which to compare. So when
> > something is called wongly it charges on to the end, evaluating blindly to
> > who knows what and we can spend hours trying to tease out the cause of a
> > missing compiler option .... but.....we are focused on the saving of a tiny
> > bit of typing.
>
> It's not the typing, it's the reading.  When 20% of the lines makes a user-defined
> function call (my situation), simplifying the function call matters.
>
> Equals and math operations can be implemented using $(shell ...).
> If you think more are needed, that sounds like a proposal, go ahead and make it.
> There's no conflict between this syntax proposal & adding more built-in functions.

This is a matter of cost of
native functions vs $(shell ...) .

Linux kernel build system highly exploits recursive building.

So, I avoid using $(shell ...) in the recursively-invoked Makefiles.

--
Best Regards
Masahiro Yamada

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

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

Tim Murphy-4


On Fri, 14 Jun 2019 at 03:17, Masahiro Yamada <[hidden email]> wrote:
On Fri, Jun 14, 2019 at 2:58 AM David A. Wheeler <[hidden email]> wrote:
>
> On Thu, 13 Jun 2019 18:18:15 +0100, Tim Murphy <[hidden email]> wrote:
> > builtin functions can check their arguments to some extent. Interesting to
> > wonder if user defined ones can.
> > we don't even have $(equals) or a way to know the number of arguments that
> > were supplied or any mathematical operations with which to compare. So when
> > something is called wongly it charges on to the end, evaluating blindly to
> > who knows what and we can spend hours trying to tease out the cause of a
> > missing compiler option .... but.....we are focused on the saving of a tiny
> > bit of typing.
>
> It's not the typing, it's the reading.  When 20% of the lines makes a user-defined
> function call (my situation), simplifying the function call matters.
>
> Equals and math operations can be implemented using $(shell ...).
> If you think more are needed, that sounds like a proposal, go ahead and make it.
> There's no conflict between this syntax proposal & adding more built-in functions.

No but as you can imagine, changes in syntax generate debate since we're all going to end up reading the next set of botched makefiles that the guy learning make has strung together in some exciting new misunderstanding for us to fix.
 
This is a matter of cost of
native functions vs $(shell ...) .

$(shell) is a big problem but it gets used because it seems like the only way to deal with the shortage of builtin functions. There is a way to build new builtin functions now and dynamically load them. Pity that doesn't seem to have been noticed much.
 
Linux kernel build system highly exploits recursive building.

So, I avoid using $(shell ...) in the recursively-invoked Makefiles.

--
Best Regards
Masahiro Yamada

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make