Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

[Dave Hart]

On Tue, Nov 22, 2011 at 21:45, Harlan Stenn <address@hidden> wrote:
> NTP pretty much runs everywhere.  It was  not that long ago that NTP
> dropped support for K&R C compilers, and at that point required ANSI C
> (and I'm not sure if it's C89/C90 or C99, but nobody has complained so I
> haven't looked harder).

NTP requires only ANSI C, also known as ISO C, C89, or C90.  It does
not require any support of later standards, though, for example, we do
rely on C99 snprintf semantics, we provide a replacement version for
use with C runtimes offering ANSI C snprintf.

>  Now that commodity x86 boxes are so "pervasive"
> there is no longer a compelling reason to support things like ancient
> sparc, mips, hp, ... boxes.

I agree the reason becomes less compelling as more capable systems
become more commonplace, but I do not agree ancient RISC boxes are no
longer an interesting target for current NTP builds.  AGC is deploying
a new PPS-synced ntpd server on his network using an ancient SPARC box
running current NetBSD.  I would be disappointed if I were telling him
he's limited to using older NTP releases because we no longer support
NTP on insufficiently common and modern hardware.  A NTP consumer at
Software AG regularly files bugs against NTP for build compatibility
breaks with ancient Sun hardware and software.  I value portability as
a concept extremely highly, and in practice I want NTP tarballs to be
as portable as we can make them, with a very short list of
prerequisites.  Our prerequisites for tarball users right now are an
ANSI C compiler, Automake-supported make (which means nearly any make
in the wild), and Autoconf-compatible shell.  Bumping those
requirements to include GNU make would reduce the package's
portability and decrease the percentage of users who try building the
tarball which eventually succeed.

> My goal is to make sure that people can easily build NTP.
>
> Toward that end I want to minimize the number of extra tools that might
> need to be installed.
>

Agreed, and easily means without additional prerequisites to me.

> I would not want to require GCC, for example.
>
> We don't require perl, but if it is there we use it.

Not from a tarball with unmodified source.  Yes, if ntpdc headers are
changed we rely on perl, and to use flock-build we rely on perl, but
neither comes into play for an end-user simply building NTP from a
tarball.

> We do not require yacc-lex/bison-flex or GNU autogen for building.  But
> if a developer wants to changes certain files, those tools will be
> needed.
>
> If there is a compelling reason to "upgrade" from current automake we'll
> do it.
>
> Some things I'd like to see would include easy non-recursive Makefiles
> (that would let folks easily build any list of given particular
> programs), and a means to integrate NTP into a larger build environment.

In other words, Harlan has indicated to me a non-recursive Makefile
sounds good in eliminating build system bugs due to each directory's
Makefile having a limited view of the whole, and I agree, but he
doesn't like the idea of giving up the ability to "make" in, say, the
ntpd subdirectory and have only ntpd and its prerequisite directories
components build, and I agree again.  If anyone knows of examples of
non-recursive Makefile implementations that manage to preserve the
recursive make property of being able to make in a subdir to make a
subset, please share so we can learn from their pioneering.

Cheers,
Dave Hart