On 2024-03-24 13:59, Paul Smith wrote:
> On Wed, 2023-12-27 at 21:45 -0800, Kaz Kylheku wrote:
>> What would be wrong with allowing the $(call ...) operator to be
>> elided?
>>
>> Instead $(call macro,a,b,c), why can't we have $(macro a,b,c), if
>> macro doesn't shadow a built-in function?
>>
>> When there are no arguments, we cal invoke it as $(macro), but when
>> there are arguments $(call ...) must be used.
>>
>> The presence of arguments can be used to deduce that a macro call
>> with arguments is to take place.
>
> I have considered doing this, but only AFTER it becomes an error (not
> just a warning) to create a make variable with whitespace in the name.
Could you elaborate? How recent of a gmake do we need for this diagnostic?
Is there another way to create variables with spaces other than something like:
VARSP := a b c
$(VARSP) = value
$(info $(a b c)) # produces "value"
for which lines should there be a diagnostic, using what GNU make versions
and options, if any? Sorry for appearing lazy, I will independently check
this myself. 4.3 is silent, so far. I have some newer installation kicking
around, as well as some project directories from past make hacking.
Anyway, so if $(call ...) can be dropped, we have the ambiguity
$(a b) refers to an "a b" variable, or invokes an "a" macro with
argument "b". I'm taking it for granted that there is some kind of warning,
suggesting that creating a variable with whitespace is a dubious construct
that is deprecated.
There is a second problem. It appears that variable names /with embedded
commas/ are allowed. Given:
FOO = A B C
BAR = A B C,
$(FOO) = FOOVAL
$(BAR) = BARVAL
$(info $(A B C))
$(info $(A B C,))
I get FOOBAR and BARVAL being printed by $(info ...). It appears that
$(A B C,) treats "A B C," as a name, which corresponds to a variable
that was created by $(BAR) = BARVAL.
In the following remarks, I'm going to pretend I didn't see
the above.
There are ways to introduce dropping the call operator, while keeping
variables with whitespace in the same deprecated status, so they
continue to work as before.
Note: in the following descriptions, I'm assuming that $(call X) has
the same meaning as $(X) when no commas are present in X.
I'm relying on $(call ...) notation as the target language
for indicating semantics.
The following table gives possible rules for handling a variable
reference containing spaces:
commas present variable exists treatment example
no yes variable $(a b c) -> $(call a b c)
$(a b) -> $(call a b)
no no macro $(a b c) -> $(call a,b c)
$(a b) -> $(call a,b)
yes -- macro $(a b c,) -> $(call a,b c)
$(a b,c) -> $(call a,b,c)
$(a,b,c) -> ??? improper form
Notes:
- When commas are present, spaces in the name are unsupported; the name
is the token before the first space; everything after that is comma
separated args.
- The "variable exists" test applies to everything in the parentheses.
If that doesn't exist, the token before the first space is tried
as the variable; everything after that is one argument.
Another different idea is to literally just drop call, without shuffling
commas around:
$(call a,b,c) becomes $(a,b,c) rather than $(a b,c)
Pro: easy, error-resistant conversion between old and new call formats.
Con: macro calls don't look like built-in operator calls: $(op arg1,arg2,...).
