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