[adding the GNU automake list, as an interested party in the current
spate of proposals for improving POSIX make; other messages start:
http://thread.gmane.org/gmane.comp.standards.posix.austin.general/3102]
On 10/15/2010 02:27 AM, tom honermann wrote:
Thanks to David Wheeler for pushing for additional standardization of
the make utility. As long as we're
on the subject, I thought I'd throw out my wish list of features I'd
like to see POSIX standardize.
GNU Automake would really like to standardize double variable indirection:
http://lists.gnu.org/archive/html/automake/2009-04/msg00040.html
- To allow to override the silencing at 'make' run time, we use of a
makefile construct with recursive variable expansion $(var1$(var2)).
This is not specified by POSIX, and so might not be portable to all
kinds of 'make' implementations. That means, if your package has the
option 'silent-rules' enabled, then even with V=1, a strict POSIX 'make'
may barf on this construct.
Now, before anyone screams: all 'make' implementations that I could get
hold of *do* accept this construct correctly; that includes IRIX 6.5,
AIX 4.3.3, Tru64 4.0D, Solaris 2.6, HP-UX 10.20, NetBSD, FreeBSD,
OpenBSD, and of course GNU; Also, we tried an alternative implementation
that uses only constructs specified in POSIX, but that turned out to be
*a* *lot* *less* portable in practice.
http://lists.gnu.org/archive/html/automake-patches/2008-12/msg00027.html
2) We replace it with a functionality that is compliant.
I thought I finally had an idea to remain compliant: you can legally
have macros on the left hand side of macro assignments. For example,
you can have
foo$(var) = bar
where $(var) is evaluated at the time this line is parsed. Of course
this allows to pass only one bit of information per $(var).
I have reworked the patch a bit to this end; see below. Unfortunately,
while this is Posix-compliant AFAICS, it is rather unportable and fails
silently with several vendor makes (e.g., IRIX, HP-UX).
I haven't found another way yet. If we can't find one, then your choice
of $(var1$(var2)) is certainly better than nothing, in combination with
(1).
--
Eric Blake ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
