[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: autoconf / automake
- From: Farmbuyer <farmbuyer@...>
- Date: Sun, 6 Nov 2011 18:30:51 -0500
On Thu, Oct 27, 2011 at 11:59 AM, Luiz Henrique de Figueiredo
> The Makefiles in the Lua tarball are meant to be portable to all variants
> of make that exist, not just GNU make. Just like Lua caters for ANSI C, not
> GNU C. But perhaps for the Makefiles this portability is pushing it. However,
> I do remember old Sun OS machines whose make was very plain. So perhaps the
> question is "What is the equivalent of ANSI C for make?".
Sadly, it's autotools. That was the specific problem the autotools were
originally created to address, in fact: non-POSIX versions of Make out there
which only implemented a bare minimum of features, or had useful extensions
but implemented them in inconsistent ways, or had some serious bugs that
needed to be worked around. Writing a *really* portable makefile to handle
all the wonky implementations of Make out there is surprisingly tricky.
"Just install GNU Make" or "Just install <some other build system>"
typically wasn't an option at the time.
For a project like Lua, which needs to be very portable, but does not have
many compile-time host tests to perform, autoconf is a bit of overkill but
automake would be more useful. Autoconf generates scriptable tests and
does text-based substitutions on the results; automake generates *very*
portable makefiles intended for autoconf to do the substitutions on.
The downside is that automake requires autoconf, although the actual
autoconf script would not need to be very big.
These days more vendor Makes are well-behaved, GNU Make itself is much
more portable than it used to be, and the hosting systems themselves are
a little more converged (you don't need to test for whether "const" works,
for example, or whether <stdlib.h> exists, or any of the really bizarre things
that occasionally happened on platforms that autoconf was designed to
handle). For a project like Lua, the autotools are likely to be overkill -- but
downstream package maintainers would love it if you kept them in mind when
making whatever decisions you see fit for your build system. For them, the
autotools are still very very useful, for their installation and