Re: Why call is not calling like native primitives? even when var is otherwise undef?

[Garreau\, Alexandre]

Le 21/05/2018 à 13h50, Paul Smith a écrit :
> On Mon, 2018-05-21 at 18:17 +0200, Garreau, Alexandre wrote:
>> On 2018-05-21 at 10:56, Paul Smith wrote:
>> > A few releases ago I made it illegal to create variable names
>> > containing spaces so the above makefile no longer works.  My
>> > intention at that time was to allow a shorthand for "call" such as
>> > you suggest, but I haven't made that change yet.
>> 
>> Also, your (still unlocalized :/)
>
> That message is localized.

I meant in my language sorry, and in debian, and actually according the
project translation page [1] it was only for the version currently
shipped in Debian, not the following.

>> What separator is it talking about exactely? The space character? the
>> equal sign? something else I’m not thinking to?
>
> That's exactly the problem.  Makefile syntax is actually fairly free-
> form, so make doesn't know that the line is really intended to be a
> variable assignment.  The only way to know the intent is by locating a
> separator; until make finds a separator the line is just a list of
> tokens.
>
> It might be intended to be a variable assignment, in which case the
> separator that's missing is "=":
>
>    foo = bar = baz

So you mean before you forbid assignment to variable with space in their
names, the separator could be = with a space before it? why don’t having
keeped this parsing behavior and then just output an according error in
this case? I don’t see the case for multiple words variable names except
when planning for named parameters…

[1] https://translationproject.org/domain/make.html