GNU Make 4.0 released

Posted Oct 10, 2013 3:12 UTC (Thu) by xtifr (guest, #143)
In reply to: GNU Make 4.0 released by madscientist
Parent article: GNU Make 4.0 released

As for Debian's position on 3.82, you'll have to ask Manoj about it. As has been pointed out here many other distributions have updated.

I don't know what's in Manoj's mind, but it may just be an excess of caution. Make is integral to Debian's packaging system—even packages that don't use make at all internally will still have their build system called by make when building the Debian package—and thus, Debian may have one of the largest collections of makefiles anywhere. (Except that most of them are named debian/rules, rather than Makefile.) With that much code to test, some care seems reasonable.

GNU Make 4.0 released

Posted Oct 10, 2013 6:14 UTC (Thu) by josh (subscriber, #17465) [Link] (5 responses)

Debian has a release-critical bug open against make 3.82 in experimental: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635317

If make 3.82 were in unstable, that bug would prevent it from migrating to testing and eventually reaching stable. Thus, it makes sense to keep make 3.82 in experimental and 3.81 in unstable as long as that bug remains open.

GNU Make 4.0 released

Posted Oct 13, 2013 20:37 UTC (Sun) by ploxiln (subscriber, #58395) [Link] (4 responses)

hilarious, it's just the wrapper code for the closed-source nvidia module. this is why we can't have nice things!

GNU Make 4.0 released

Posted Oct 13, 2013 21:06 UTC (Sun) by josh (subscriber, #17465) [Link] (3 responses)

That's where the bug was originally filed, but the makefile in question was actually in the kernel headers.

GNU Make 4.0 released

Posted Oct 13, 2013 21:42 UTC (Sun) by madscientist (subscriber, #16861) [Link] (2 responses)

Yes, this bug should have been re-targeted at the kernel headers package and fixed there. It is absolutely not a release-critical bug against GNU make. This is simply a bug triage failure.

The upstream kernel headers had been fixed in Linux kernel version 2.6.34, and there's no excuse for the Debian linux-headers-3.0.0 package to still be using Makefiles from a release older than that.

For what it's worth, I checked the version of linux-headers in wheezy (linux-headers-3.2.0-4-amd64) and it doesn't appear to have this problem, so this bug should be closed anyway.

GNU Make 4.0 released

Posted Oct 13, 2013 22:03 UTC (Sun) by josh (subscriber, #17465) [Link] (1 responses)

It's a regression in make for not handling makefiles it used to handle. And not only that, it's getting fixed upstream; someone figured out that by changing the error about mixed targets to a warning, the code itself actually still works as well as it used to.

GNU Make 4.0 released

Posted Oct 13, 2013 23:32 UTC (Sun) by madscientist (subscriber, #16861) [Link]

I'm sorry, but that's wrong. The bug referred to here is a bug in the linux-headers package. The linux-headers package for the 3.0.0 kernel should be using the module build system provided with the 3.0.0 kernel. If it were, everything would work regardless of the version of GNU make installed. That's the bug. Full stop. And it appears to have been fixed in the linux-headers 3.2.0 package in wheezy.

You may feel that there is some other bug that should be filed, such as "compiling kernels older than 2.6.34 on my Debian system with GNU make 3.82 fails, while it succeeds with GNU make 3.81". That definitely belongs in the GNU make bug list. Then the question becomes whether that should be release-critical (I would argue "no" but I'm not the Debian maintainer so it's not up to me), and what to do about it if the upstream maintainer does not consider it a bug.

It's not a goal of GNU make, now or ever, to always handle every makefile that it used to handle at any time in the past without change. New releases of GNU make introduce new features. Because of the free-form nature of makefile syntax it's sometimes not feasible to add a feature without _potentially_ causing some makefile, somewhere, to change behavior. These potential changes, along with workarounds, are documented in the NEWS file.

If the requirement for GNU make to avoid being held back by Debian is that it always "handle [all] makefiles it used to handle", then it's unlikely Debian will ever update GNU make to any later version. That's their choice of course. Then when some package somewhere requires a newer version of GNU make in order to build correctly, they'll have to decide how to handle that.

> And not only that, it's getting fixed upstream

In the next version of GNU make there will be a change to make this particular problem a non-fatal error, since that turned out to be not very difficult. That doesn't undo any of the other numerous backward-incompatibilities added in GNU make since 3.81, so it does not mean that GNU make now magically "handles makefiles it used to handle", in general. Further, there's no guarantee that this particular problem won't become a fatal error again in future releases, if makefile syntax changes such that maintaining it becomes too onerous.

But if all you are _really_ concerned about is building versions of Linux older than 2.6.34 with a newer version of GNU make, then the next release should offer relief.