Subject: Re: FW: Re: CVS commit: src/usr.bin/make
To: Simon J. Gerraty <email@example.com>
From: Marc Espie <firstname.lastname@example.org>
Date: 09/07/2003 01:10:58
> From: email@example.com (Simon J. Gerraty)
> Date: Sat, 6 Sep 2003 15:05:44 -0700 (PDT)
> To: firstname.lastname@example.org (Christos Zoulas)
> Cc: email@example.com, firstname.lastname@example.org
> Subject: Re: CVS commit: src/usr.bin/make
> >In article <20030906065210.5AA1DB004@cvs.netbsd.org>,
> >Simon J. Gerraty <email@example.com> 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
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).