On 12/06/2011 08:10 PM, Daniel Richard G. wrote:
> On Tue, 2011 Dec  6 16:26-0700, Eric Blake wrote:
>>
>> Yes, since we already do other configure checks for make capabilities,
>> and substitute that into Makefile.in when producing Makefile.  And no
>> one said we have to run all the checks on all the platforms - it may
>> be sufficient to detect multiple features on a single make probe run,
>> at least for GNU make, to minimize forking in the common case.
> 
> That would help, surely. But I don't see why you would want to add yet
> another moving part if there were a way to avoid it. I mean, if $({})
> violated POSIX,

Yes, use of $(${}) is specifically unspecified by POSIX 2008, and use of
that extension means you are on unportable ground.  The goal is that
POSIX 201x will require it, and that eventually make implementations
will catch up to POSIX, but we aren't there yet.

> or there were known implementations that could not
> tolerate curlies, then sure.

There are systems that cannot tolerate the extensions to existing POSIX
2008 (of which, $($()) is one such extension): at least nextStep and
nonstop.  Doing a configure-time check of make capabilities will let us
write portable makefiles even for those systems, while using $(${})
would avoid the configure check, and would even work around the nextstep
limitations, but would not necessarily work for nonstop or for POSIX
2008 implementations.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org