Make compatibility requirements

While overhauling CPython’s build system to fix a ton of longstanding warts, I stumbled across a line that implies that CPython must support building on make implementations not supporting pattern rules. (GNU Make introduced pattern rules before other make implementations grew support.)

I couldn’t find any in-repo documentation specifying which make implementation / version / features are supported/required. CI coverage only seems to build with GNU Make (macOS even uses GNU Make 3.8).

Is there a requirement to support non-GNU Make?

If so, which implementations and versions?

If so, perhaps configure should perform make feature detection so we can codify those requirements and reject incompatible make implementations before builds fail in obtuse ways?

I ask because there are potential [GNU] make features I’d like to use to improve the build system and it isn’t clear to me what hidden requirements exist preventing their use. My understanding is that most environments these days have access to GNU Make, even if make isn’t GNU Make by default. So requiring certain [initially exclusive to] GNU Make features may not be such a big deal after all.

Thanks in advance for enlightening me.

At least years ago, the CPython makefile supported “make” other than GNU make. I tested with NetBSD “bmake” on Linux and it still appears to work. However, according to PEP 11, modern CPython tries to support many fewer platforms (e.g. no Solaris, no HPUX, no AIX, no IRIX). I’m not sure any of the platforms currently supported actually use a non-GNU make. Perhaps FreeBSD? If they currently use BSD make the I would guess they probably could switch to using GNU make.

I would cautiously support that idea, but only after confirming that none of the tier 1, 2 and 3 platforms have a problem with using GNU make. Perhaps you need to contact the people associated with each platform, according to PEP 11, and confirm requiring GNU make is not an issue?

2 Likes

If you do this, please mention it in the What’s New. Also, at this point consider targetting 3.13 so it has the full alpha/beta testing period (the branching should happen next week).

As for PEP 11, I’ve always interpreted its intention as not having to maintain workarounds/optimizations for niche platforms, rather than allowing use of features that happen to exist on all the tiered platforms. IMO, CPython should still stick to POSIX, C standards, etc. by default.
So I don’t think we should only look at PEP 11 platforms here.

But, PEP 11 doesn’t explicitly say that. Perhaps it should.

3 Likes

I’m fine with the idea of requiring gnu make 3.8+ (or whatever the ancient version that macOS xcode ships is) – if there is compelling pain that can be removed from our Makefile behavior and maintenance by doing so. It is easy enough to build gnu make on any platform that lacks it by default and is trivial to do for all of our PEP-11 tier1-3 platforms.

The larger issue is that we should really move away from autoconf and make entirely. But don’t block on that concept. It’s a separate rabbit hole that has so far not seen anyone with the patience to lead us to settlement on what the actual requirements are.

Recently, I added a Build Requirements section to the Python documentation. If we have requirements on a specific make feature or version, I suggest to document it there.

In the past, we tried to stay compatible with the make commmand available on FreeBSD: FreeBSD make.