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: David A. Wheeler
Subject: Re: Idea: Allow $(name ...) as an abbrevation of $(call name ....)
Date: Mon, 10 Jun 2019 18:27:22 -0400 (EDT)

On Mon, 10 Jun 2019 22:46:23 +0100, Tim Murphy <address@hidden> 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


reply via email to

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