Follow-up Comment #18, bug #33034 (project make):
> That's disappointing.
I've already explained why. Makefile syntax, unlike the C ABI where you can
always just define a new function, is not inherently extensible except in very
limited ways, and I'm not interested in creating ever more obscure syntactical
aberrations and/or adding tons of special backward-compatibility flags with
their attendant headaches. In my opinion makefiles already have more than
enough syntactical foibles. Take a look through the actual
backward-compatibility issues raised in the NEWS file.
Of course, this is open source so you're free to provide a version of GNU make
that _does_ provide these types of options for backward compatibility, if you
feel it's that important.
My opinion on backward-compat is that we make an effort to avoid
backward-incompatibilities and try to ensure they have the smallest possible
impact. This change would likely have never been noticed if it hadn't
affected Linux, and it would not be a big deal (only 3 files needed to be
changed) except so many people apparently want to build old versions of the
kernel. How many people go back and build OpenOffice 1.0 on their brand new
Ubuntu 14.04 systems, and so would care if the OpenOffice 1.0 makefiles no
longer worked with GNU make 4.0?
If you cannot change your makefiles to avoid the backward-compat issues, you
can always keep multiple versions of GNU make. Unlike other tools like Java,
GCC, etc. make is a single, simple executable that can be placed anywhere you
want and named anything you want, and it will continue to work just fine.
Take two, they're small!
> I'm curious what you infer that from.
Two things from the manual: first the description of pattern rules explicitly
describe what happens if you include a non-pattern prerequisite, but says
nothing about allowing a non-pattern target. Second GNU make lists the
different types of lines in a makefile and none of those allows a mash-up of
implicit and explicit rules like this.
And two things from experience: if you write "foo bar%:" it works, but if you
write "bar% foo:" it fails with an error. Also if you add a pattern
prerequisite "foo bar% : baz%" that also fails to work (the target 'baz%',
literally, is considered a prerequisite of the target 'foo'). Certainly any
syntactical rules _THAT_ obscure _WOULD_ be mentioned explicitly in the
manual, if this were intended to be a supported feature.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?33034>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
