Follow-up Comment #16, bug #33034 (project make):
I admit I didn't understand the frustration level with this change. The Linux
kernel was the only package that ever reported any real issues, and there were
(by my count) a total of three patches (all minor) over the span of a couple
of months after the 3.82 release in 2010 to fix those problems.
The release-critical bug in Debian is, IMO, completely unjustified (and I
didn't know about it anyway). That bug should (a) not be release-critical,
and (b) should be filed against the Linux kernel headers package, not GNU
make.
If it turns out that simply changing the fatal() to an error() is sufficient
to resolve this, I'm willing to make that change (I won't add a flag for it;
the message will simply say the syntax is unsupported and should be updated).
HOWEVER, I'm not willing to guarantee that this syntax will continue to be
supported going forward. GNU make is not the kernel, and I reject attempts to
impose the development ethos of the kernel on GNU make. The syntax of
makefiles is so free-form that virtually any enhancement that is made will be
a backward-compatibility issue and I'm simply not willing to commit to that
kind of restriction. The kernel can always just introduce a different
function name with new semantics--not so for makefiles. If people need that
level of backward-compatibility I recommend they simply keep around multiple
versions of GNU make to support older code; make's installation is trivial,
just the one program with no extra support files, and even after renaming it
works flawlessly.
In this particular case I expect that even if the syntax still can be made to
work now, when we support the ability to define explicit rules with multiple
targets generated from a single recipe invocation, this syntax might not
survive. The fact is that this usage IS illegal according to the
documentation (it may not be explicitly proscribed but writing down all the
things that are NOT legal is an impossibility--it's easily, IMO, inferrable
that the syntax is not intended to be valid).
I am not willing, at this point, to embrace the idea of "fixing" it so this
syntax works fully and making it legal. In my opinion it will be simply too
confusing and difficult to manage all the edge cases around trying to combine
two (or more, in the future) different rule models into a single statement.
I'm willing to look at any proposals someone has, but I warn you I'll be
extremely skeptical. I just don't think it's that big of a deal to write the
rules separately, so any proposal will have to be VERY compelling to justify
the complexity given the trivial alternative.
_______________________________________________________
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
