[bug #33034] "Makefile:23: *** mixed implicit and normal rules. Stop." for Linux kernel out of source builds

[Josh Triplett]

Follow-up Comment #8, bug #33034 (project make):

Re comment #5:

GCC is *exceptionally* careful about introducing backward-incompatible changes
that break existing codebases, to the point where it provides options like
-fpermissive to help older code continue to build.  As long as you don't
blindly use options like -Werror, GCC generally doesn't break older codebases,
for exactly this reason.  The rare times it has, notably the time that led to
the introduction of the -fno-delete-null-pointer-checks option now used in the
Linux kernel and other projects, have been huge debacles that generated
incredible pain in numerous projects.

On top of that, GCC's rare instances of making parsing more strict have
generally either been for standards compliance or to introduce some new
feature or optimization that depended on the stricter behavior.  The release
notes for make 3.82 don't give any indication about why make no longer accepts
pattern rules and explicit targets in the same rule, just that it doesn't. 
What motivated this change, and what amazing enhancement to GNU make does it
allow that would not be possible while retaining that behavior?

This backward-incompatibile change makes it impossible to build older versions
of the Linux kernel with current make, which breaks features like "git bisect"
(for tracking down a bug in a range of kernel versions down to a specific
commit).  It means that, for years to come, users will need a copy of
make-3.81 sitting around, and have to know to use that for building older
software when they see that particular error message.  And this change is the
reason why make 3.82 is still sitting in Debian experimental and won't go into
unstable anytime soon.  (And all the amazing features of make 4.0 seem likely
to sit in experimental for a long time for the same reason.)

Given all that, is there any fundamental reason why make couldn't support this
behavior for backward compatibility, either by default, or at least with an
option to turn on that backward compatibility?  In particular, would you
consider merging a patch to that effect if someone else wrote it?


Re comment #7: Please do, that would be highly welcome.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?33034>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/