Re: bmake bug with expanding pattern macro replacements

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

David Holland <dholland-tech%netbsd.org@localhost> wrote:

> On Sat, Apr 25, 2020 at 02:44:00PM +0200, Joerg Schilling wrote:
>  > 	https://www.austingroupbugs.net/view.php?id=519#c1206
> 
> BSD make is not POSIX make (this has come up before) and in general
> the archaic sysv substitution behavior isn't useful anyway; in BSD
> make you should be using the S modifier, or C if you want regexps.

Do you believe you need a better method since the standard method only 
works in 100% of the cases?

You could get a time machine, go back for 35 years and convince the other 
people to use your idea, but wait - you would first need to go back 40 years
in time to invent a portable regular expression interface for libc....

If you like me to be able to support the deviations from bmake, I would 
first need to be able to identify bmake in order to be able to do something
like 

	include ${MAKE_PROGRAM}.rul

in order to have the nonstandard stuff in that file. First I need to be able
to fill in a program specific name into MAKE_PROGRAM - of course in a portable
way....

> I notice that you have only taken eight and a half years to mention
> this to us after discussing it in the POSIX issue tracker.

Well, 20 years ago, there was a conversation with FreeBSD people and 
they fixed the problems with pattern macro substitution.

Unfortunately, BSD make had many other deviations from a standard make 
behavior that it was not useful for a portable set of makefiles. I recently 
started an attempt to check whether bsd make may have become useful.

So the main question is whether you like to have a compatible make 
implementation (potentially with non-standard extensions) or whether your make 
continues to be incompatible to all other make implementations in basic 
behavior already.
 
> I guess it's a bug. I suppose maybe in late 2028 someone will get
> around to fixing it.

Then NetBSD may become close to GNU software, where it takes at least 22 years 
to get an accepted bug fixed.

My previous experience with a bug in waitid() (that delivered only 8 bits from 
the exit code) was different:

-	FreeBSD did take 22 hours to fix the bug

-	NetBSD did take a month to fix the bug

-	Linux needed 2 months to reply that they are not interested
	to fix the bug.

I am still open for a try.

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/