On Tue, Nov 22, 2011 at 21:45, Harlan Stenn <st...@ntp.org> 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
