[Zlib-devel] Use autoconf for zlib?

[Cosmin Truta]

On Tue, 11 Apr 2006, Mark Adler wrote:

> I'm considering going to Autoconf, Automake, and Libtool for zlib.
> I am just now looking at them, and otherwise have no experience
> developing with them.

IMHO the learning curve is not steep, but it's not trivial, either.

Someone suggested the introduction of a zlib.pc file for pkgconfig.
That would be good for zlib-based application that use this sort of
configure scripts, so I have nothing against it.

> I'd like to think that this would make my life easier in the long
> run, but I'm not sure.

In practice, no.  In theory, some say yes, some say no, and I also say
no.

>From a practical point of view, I'd say IIABDFI.  So far, there was
noone reporting "zlib build fails on system X, please apply this
whopping and hardly-manageable patch to the configure script", and I
doubt someone ever will.

This is no accident.  The current configure script is checking for gcc,
(v)(s)nprinf, unistd.h and mmap.  Even if the configure script is not
executed, the build still works, because cc traditionally exists on all
Unices, and the other stuff is not mandatory.  Things may be different
for programs like TAR that heavily depend on system-specific features;
but zlib builds fine on any system with decent C89 library support, and
not much else.

In theory, however, it is always possible that someone will eventually
come and say that you need to fix the config headers and/or scripts in
order to build zlib on some weird system.  Now, there's the choice of
updating configure (which IMO is easy to do, because zlib's particular
configure script is fairly small and easy to maintain), or the choice of
updating automake/autoconf scripts and add a large amount of junk along
the way.  The automatically-generated configure is humongous and nearly
impossible to hack.

I would be okay with auto-generated configure and Makefile if it were a
do-it-once, never-touch-it-again solution.  But it isn't.  The Makefile
needs to be automake'd each time there's a change in the list of source
files.  The configure script needs to be re-autoconf'ed because there
will always be new systems.  So run autoconf every once in a while, and
be prepared for compatibility issues between what you used to have and
what you're having now.

Sure, I'm speaking from my own experience, which might be irrelevant to
the experienced autotools user.  My point is: if you don't know these
tools well enough, be prepared for the unforeseen.

Last but not least, there's the issue of having an incomplete or broken
libc, in which case it could be hard to work around without the help of
some tools like these auto* things.  (Did anyone see messages like
"checking for string.h" or "checking for memcpy"?)  I personally have no
sympathy for those systems.  We are 17 years away from C89, and I cannot
understand why cripple the readability of almost every piece of portable
software for the sake of a few people who cannot upgrade their antique
systems.  If they're satisfied with what they used to have 17 years ago,
why would they need zlib?


Best regards,
Cosmin