Re: FW: Re: CVS commit: src/usr.bin/make

[Marc Espie <espie%nerim.net@localhost>]

> From: sjg%crufty.net@localhost (Simon J. Gerraty)
> Date: Sat,  6 Sep 2003 15:05:44 -0700 (PDT)
> To: christos%zoulas.com@localhost (Christos Zoulas)
> Cc: source-changes%netbsd.org@localhost, sjg%crufty.net@localhost
> Subject: Re: CVS commit: src/usr.bin/make
> 
> >In article <20030906065210.5AA1DB004%cvs.netbsd.org@localhost>,
> >Simon J. Gerraty <sjg%netbsd.org@localhost> wrote:
> 
> >>Make empty() consider an undefined variable as empty,
> >>rather than throw a syntax error.
> 
> >I had considered doing this many times, but it needs to be coordinated
> >with the other BSD's, otherwise we'll end up with makefiles that run
> >only in our version of make.
> 
> I'm all for cross pollination, but to a large extent we have that issue
> today.  Our makefiles are full of cool stuff like :@ :U etc which
> the other BSD makes lack (or worse have a different meaning for).  
> I spent some cycles a few years ago trying to remedy that and came 
> to the conclusion it simply wasn't going to happen.

Meaning for :U and :L in OpenBSD predates the corresponding change in
NetBSD.

Did you even inform us that you were going to add some incompatible :U
in NetBSD make before it happened ? Nope. I just discovered it while
trawling for useful changes in your tree.

The best way to handle modifiers is the approach I took for op-packages:
making it possible to have any possible meaning as `personalities'. The
modifiers handling is done in a sufficiently modular way in op-packages
that adding new modifiers and changing behaviors is somewhat easy.

Since then, you have added lots of modifiers to make. I'm not sure I
like the direction this is going, because every single modifier you
are adding, especially the non-uppercase ones, is running a larger
chance of interfering with normal SystemV modifiers.

Rather, OpenBSD has taken the path of streamlining make for speed, with
fairly reasonable results so far.

I don't have that much time to hack on make, but I would rather focus on
more mainstream, useful stuff, like having a better VPATH implementation
so that we don't need to rely on gnu-make so much on ports, for instance.
(the problem being that VPATH look-up only occurs on files, not targets,
but needs to happen on targets to be truely useful).