Re: recursive make variables coming to POSIX

[Eric Blake]

[adding the Austin Group; this is in regards to
http://austingroupbugs.net/view.php?id=336, and this email implies that
we may want to tweak the wording and restart the 30-day interpretation
window if it is important to not invalidate existing IRIX behavior]

On 12/05/2010 08:50 PM, Ralf Wildenhues wrote:
> Hi Eric,
> 
> * Eric Blake wrote on Thu, Dec 02, 2010 at 08:21:13PM CET:
>> On 12/02/2010 12:10 PM, Ralf Wildenhues wrote:
>>> I'm not sure if it was mentioned before in the discussion, but
>>> portability-wise, there is a difference between one level of recursion
>>> and arbitrary many.  IIRC then IRIX make only supported one level, i.e.,
>>>   $(var1$(var2$(var3)))
>>>
>>> was erroneous, but
>>>   $(var1$(var2))
>>>
>>> was not.  Also, with a one-character variable X
>>>   $(var$X)
>>>
>>> was erroneous with at least one legacy make implementation (but I think
>>> it was more than one); but
>>>   $(var$(X))
>>>
>>> worked.
>>>
>>> If you like, I can go back and verify the details.
>>
>> Yes please, and I will feed that information back to the Austin Group.
> 
> Thank you.  Here we go.  With the following Makefile,
> 
> V = v
> V1 = v1
> V11 = v11
> O = 1
> ONE = 1
> O1 = 11
> Vr1 = $(V$(O))
> Vr2 = $(V$(ONE))
> Vr3 = $(V$(Z))
> Vr4 = $(V$O)
> Vr5 = $(V$Z)
> Vrr1 = $(V$(O$(Z)))
> Vrr2 = $(V$(O$(O)))
> Vrr3 = $(V$(Z$(Z)))
> Vrr4 = $(V$(O$Z))
> Vrr5 = $(V$(Z$Z))
> R = R
> Vrrr = $($($($($($($($($($($($($($(R))))))))))))))
> all_FLAGS = bar
> 
> all:
>       @echo $(Vr1), $(Vr2), $(Vr3)
>       @echo $(Vrr1), $(Vrr2), $(Vrr3)
>         @echo $(Vrrr)
>       @echo $(Vr4), $(Vr5)
>       @echo $(Vrr4), $(Vrr5)
>       @echo $(address@hidden)
>       @echo $($(@)_FLAGS)
> 
> the make implementations from
>   AIX 5.2, 5.3, 6.1, 7.1
>   Darwin 10.4.0 (GNU make 3.81)
>   FreeBSD 6.4, 7.1
>   GNU
>   HP-UX 10.20, 11.00, 11.11, 11.23, 11.31
>   NetBSD 5.99.39
>   OpenBSD 4.4
>   Solaris 2.6, 7, 8, 9, 10
>   Tru64 OSF 5.1D
> 
> all print:
> 
> v1, v1, v
> v1, v11, v
> R
> v1, v
> v1, v
> bar
> bar
> 
> IRIX 6.5 make fails over each expansion in output lines 4, 5, and 6,
> e.g.:
> 
> v1, v1, v
> v1, v11, v
> R
> UX:make: ERROR: Unmatched closing curly braces or parenthesis in line 
> containing:
>         $(V$O).
> 
> 
> The last line containing $($(@)_FLAGS) is wrongly expanded to empty by
> this make.
> 
> 
> So, in summary, the parenthesization is an issue, and expanding of the
> automatic $@ variable recursively.  I haven't tried to determine whether
> there is an upper limit to recursive expansion (should I?).
> 
> See also this old thread:
> <http://thread.gmane.org/gmane.comp.sysutils.automake.general/9943/focus=9945>
> 
> Cheers,
> Ralf

Thank you, Ralf, for providing this additional research.

Hmm, we also haven't really tested other corner cases, such as ${V${O}}
instead of $(V$(O)) (braces instead of parenthesis), $(V${O}) or
${V$(O)} (mixing braces and parenthesis), or $(V:$(O)=2) (recursive
expansion inside substitutions).

Meanwhile, this may work as an appropriate wording that still permits
IRIX behavior, by stating that recursive expansion is only specified for
parenthesized variables that are not one of the five internal macros (@,
%, ?, <, *), and only when nested with () or {}:

Change line 95800:
"The parentheses or braces are optional if string1 is a single character."
to:
"The parentheses or braces are optional if string1 is a single
character, except when the expansion is nested inside another macro
expansion."

Lines 95801-95802 and 95807-95808 both contain:
"If string1 in a macro expansion contains a macro
expansion, the results are unspecified."
In both cases, replace them with:
"If string1 in a macro expansion contains a macro expansion where the
inner expansion uses parenthesis or braces and is not an internal macro,
that inner macro expansion shall be recursively expanded before use.
Any other form of macro expansion in string1 has unspecified results."

as well as listing in the rationale examples such as $($(@)_FLAGS) and
$(V$O) that are unspecified.

Also, we should probably modify the wording at line 95807 to mention
nested macro expansions in subst1 or subst2, although it will require
more testing of make implementations to determine whether $(V:$(O)=2) is
well-defined or unspecified in practice.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature