Re: bmake bug with expanding pattern macro replacements

[(Joerg Schilling) <schily%schily.net@localhost>]

Robert Elz <kre%munnari.OZ.AU@localhost> wrote:

> Overall I think I concur that no-one, ever, should go anywhere near this
> disaster of an incredibly badly designed and documented feature - it is
> no wonder that POSIX says the results are unspecified.

The feature is well designed, but gmake does not implement it correctly.
This is why the POSIX standard did call parts of it unspecified.

BLA=test
XXX=12%34
PER=12%

all:
	echo $(BLA:%st=aaa) $(BLA:%st=A%B) $(BLA:%st=A%B%C)
	echo $(XXX:12\%%4=A%B) $(XXX:${PER}4=A%B) $(XXX:1%%34=%)

shows that gmake implements a backslash to escape the patter funtion but on the 
other side only supports "zero of one" instead of the designed "any number of %"

smake and SunPro make on the other side are 100% compatible with respect to 
that feature.

If you like to prevent badly implemented GNU software from causing POSIX to 
call GNU implementation bugs "unspecified", we would need more people that 
regret to let GNU bugs to affect the standard.

Jörg

-- 
EMail:joerg%schily.net@localhost                  (home) Jörg Schilling D-13353 Berlin
joerg.schilling%fokus.fraunhofer.de@localhost (work) Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/