On Sat, Jan 11, 2020 at 10:54:02AM +0100, Niels Möller wrote:

Hi,

it's been pointed out to me that GNU make documentation of old-fashioned suffix rules say

: Suffix rules cannot have any prerequisites of their own. If they : have any, they are treated as normal files with funny names, not as : suffix rules. Thus, the rule: : : .c.o: foo.h : $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $< : : tells how to make the file '.c.o' from the prerequisite file 'foo.h',

Nettle's Makefile.in has a rule

.asm.$(OBJEXT): $(srcdir)/asm.m4 machine.m4 config.m4

which is broken according to these docs. I haven't seen any problems in practice (not entirely sure why), but it reportedly fails with some GNU make prerelease.

To change this to a %-pattern rule, I wonder: Should we just drop support for non-GNU make programs?

Requiring GNU make makes a few things easier: We can use %-patterns everywhere. We can use -include unconditionally for dep-files, dropping the @DEP_INCLUDE@ variable and the dummy-dep-files configure step. We can most likely also drop all logic for the testsuite/.test-rules.make file.

Current status of make compatibility is that it's supposed to work with Solaris make (but likely not tested for a long time), and it should kind-of work with BSD make, provided one configures with --disable-dependency-tracking.

Is there any platform that is considered a supported build target for nettle, which does /not/ have GNU make easily available ? I doubt it. It is a mere "pkg add gmake" on *BSD to install it.

So I'd flip the question. Is there any compelling benefit to supporting non-GNU make ? If 95% of development is done & testing with GNU make on Linux, then I think it is beneficial to mandate GNU make for all non-Linux too. This cuts down the testing matrix and should lead to more reliable and consistent build system across platforms, as well as letting nettle take advantage of GNU make features.

As a reference, with QEMU/libvirt we've mandated GNU make for along time and never had any users complain about this dependancy. The only irritation is that devs sometimes forget and just type "make" instead of "gmake" and then get wierd errors due to GNU extensions, but they quickly realize their mistake & move on.

IOW, I'd encourage mandating GNU make for any project. It is just not worth the effort to worry about random vendor specific make impls when GNU make is available everywhere that matters.

Regards, Daniel

On Sat, 11 Jan 2020 10:54:02 +0100 nisse@lysator.liu.se (Niels Möller) wrote:

Hi,

it's been pointed out to me that GNU make documentation of old-fashioned suffix rules say

: Suffix rules cannot have any prerequisites of their own. If they : have any, they are treated as normal files with funny names, not as : suffix rules. Thus, the rule: : : .c.o: foo.h : $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $< : : tells how to make the file '.c.o' from the prerequisite file 'foo.h',

OpenBSD make(1) agrees that a suffix rule has "no prerequisites", but doesn't enforce this. The above rule, in OpenBSD make, is a suffix rule:

$ make file.o `file.o' is up to date. $ touch foo.h $ make file.o cc -c -O2 -pipe -o file.o file.c $ make .c.o make: don't know how to make .c.o Stop in /tmp/proj

https://man.openbsd.org/make#INFERENCE_RULES says,

: A complete inference rule is a dependency line with such a target, : the normal dependency operator, no prerequisites and a list of shell : commands.

Over in NetBSD, https://netbsd.gw.com/cgi-bin/man-cgi?make seems not to mention whether a suffix rule can have prerequisites.

...

To change this to a %-pattern rule, I wonder: Should we just drop support for non-GNU make programs?

Requiring GNU make makes a few things easier: We can use %-patterns everywhere. We can use -include unconditionally for dep-files, dropping the @DEP_INCLUDE@ variable and the dummy-dep-files configure step. We can most likely also drop all logic for the testsuite/.test-rules.make file.

I often install GNU make on OpenBSD, because I build software that uses %-patterns, $(shell ...) calls, or GNU-style ifdef/endif in Makefiles. BSD make already has -include.

Current status of make compatibility is that it's supposed to work with Solaris make (but likely not tested for a long time), and it should kind-of work with BSD make, provided one configures with --disable-dependency-tracking.

I don't know if BSD make can build Nettle; I used GNU make.

The BSDs appear to use GNU make to build their Nettle packages. In OpenBSD ports/security/libnettle [1], the line "USE_GMAKE= Yes" uses GNU make. FreeBSD [2] and NetBSD [3] appear to also use gmake. It is as if Nettle already requires GNU make.

I wonder if we can find anyone who doesn't use GNU make for Nettle.

--George

[1] https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/security/libnettle/Makefile?... [2] https://svnweb.freebsd.org/ports/head/security/nettle/Makefile?revision=5122... [3] http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/security/nettle/Makefile?rev=1.22...