Re: bmake bug with expanding pattern macro replacements

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

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

> Assume I want to do
> 
> 	${var:abc%def=pqr%-\%-%xyz}
> 
> (where the \% has the obvious intended meaning, not how it works in smake)
> and explain how to do that (given that "var" might possibly not start with
> abc or end with def, or might) using the technique you suggested?

I never had the need to do this and I am using this feature heavily since 34 
years.

Regarding your proposal that is derived from GNU make behavior, this is a 
problem as this special treatment of \ in GNU make causes portability problems
on MS systems, where \ is part of filenames and since GNU make does not follow
the rule "evaluate the \ character only where it has a well defined behavior 
in POSIX".

smake works fine on MS systems without having MS specific #ifdefs in it's code.
gmake has plenty of such #ifdefs and still fails in many cases on such MS 
systems, caused by it's \ handling.

Implementing your wish would also break a central feature in the OpenSolaris
Makefile system:

PRE_POUND=		pre\#
POUND_SIGN=		$(PRE_POUND:pre\%=%)

than depends on the POSIX definitions for make to include \ literarily in
PRE_POUND.

If you have a proposal to enhance the usability of pattern macro expansions
for the last per million... without breaking current behavior, you are welcome.


>   | I cannot confirm your interpretation of the background. Before gmake
>   | has been introduced in 1989, the most widely available make
>   | implementation has been SunPro Make
> 
> At that time, as I recall it, the most widely available make (if one
> can call anything available when licensing restrictions still applied)
> was Bell Labs make, which had none of this nonsense.

In the time between 1977 and 1985, the Feldman make really was the most widely 
available implementation, as the second implementstaion (the UNOS make from 
1980 written by some former AT&T employees that founded Charles River Data 
Systems) had only a few thousand installations.

Starting with SunPro Make, this has been SunPro Make since SunOS was the 
dominant UNIX installation these times. This caused e.g. that GNU software was 
developed on SunOS for SunOS.
 
>   | It may be, but unfortunately, I cannot check this, since not the apparently
>   | 2 year old "bmake" has been modified,
> 
> I don't know the procedures for exporting the NetBSD make into bmake
> so I cannot help with that.

This is bad. If I cannot test, it makes no sense for me to spend more effort 
in bmake, because it is unlikely to become usable within the forseeable time.

>   | What kind of proprietary software are you talking about?
> 
> SunPro, back at the time any of this mattered (long before Solaris
> was open sourced).   And you know that.

SunPro make is no more proprietary than GNU make or BSD make and you should 
know that, since proprietary in not the contrary of opensource but marks 
something that is different from the rest. In this context, bmake seems to be 
the make implementation with the most proprietary behavior. I remember e.g. 
that the behavior for VPATH is not compatible to what other make 
implementations do... and there are other deviations that need to be discussed 
in case that it should become usable for portable software not designed for 
only bmake.



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/