[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why call is not calling like native primitives? even when var is oth
Re: Why call is not calling like native primitives? even when var is otherwise undef?
Mon, 21 May 2018 20:10:54 +0200
Gnus (5.13), GNU Emacs 25.1.1 (x86_64-pc-linux-gnu)
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  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
> 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…