Re: make: avoid breaking backwards compatability

[David Holland <dholland-tech%netbsd.org@localhost>]

On Wed, Sep 03, 2014 at 10:25:38PM +0000, Christos Zoulas wrote:
 > >...basically you're saying that pattern rules no longer work for these
 > >cases.
 > 
 > Let's not call "suffix rules" (aka in the POSIX docs "inference rules")
 > "pattern rules" because "pattern rules" are something totally different.

ok fair enough.

 > Actually "pattern rules" were invented to generalize "suffix rules", and
 > address exactly this case.

How? Writing "%.o: %.c" doesn't give you any more control than writing
".c.o:". While you can write "%.o: %.c" and then a separate rule
"foo.o bar.o: %.o: foodir/%.c", or maybe that in the opposite order,
then you have to cut and paste the commands. Not a winner.

If all your sources are in a *single* other directory you can handle
that with pattern rules instead of .PATH, but in that case the issue
at hand doesn't arise.

 > >Note that I've been saying for years that .PATH and pattern rules for
 > >non-local files are bad and that makefiles shouldn't be written in
 > >this style; but that doesn't mean the feature should be arbitrarily
 > >lobotomized.
 > 
 > Well, the problem is that now "suffix rules" cannot be controlled.

Yes, precisely.

I don't think we should cripple the behavior of BSD make suffix rules
just because they include features POSIX didn't anticipate and doesn't
support.

Unless we want to make a stand and remove suffix rules entirely. I
would probably go along with that, but it's tilting at windmills...

 > NOTE: We depend on a large number of non-portable bsd-make features for
 > our Makefiles anyway, and this is not easy to correct.

Just to begin with, the .include directive... or do you mean not
portable to other dialects of BSD make?

There's absolutely no point trying to rewrite NetBSD's build system to
use strictly portable makefiles, regardless of whether 'strictly
portable' means the common subset of BSD make, GNU make, and SVR[2-4]
make or it means the amalgamation of GNUisms into SVR4 make that's
made it into POSIX. Neither of those subsets is anything like powerful
enough to handle a complex build system in a pleasant fashion.

The only question is whether 3rd party makefiles written for one of
those subsets work in our make; in the first case they will
definitionally (unless we totally break what "BSD make" is) and it's
not clear that the second is actually interesting.

-- 
David A. Holland
dholland%netbsd.org@localhost