[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bmake bug with expanding pattern macro replacements
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
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
> 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
> 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.
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/
Main Index |
Thread Index |