Re: autotools alternatives, is anybody using autosetup?

[William Ahern <william@...>]

On Mon, Jul 16, 2012 at 05:32:59PM -0700, Sam Roberts wrote:
> On Fri, Oct 28, 2011 at 7:22 PM, Michael Richter <ttmrichter@gmail.com> wrote:
> > The Fossil[1] community had this whole process not all that long ago.
> > Automake/autoconf were rejected as not being portable and being in general a
> > complete pain in the lower torso anatomy to use.  The solution that was used
> > in the end was a little piece of software called autosetup[2].
> 
> Has anybody been using autosetup with lua projects?
> 
> I've been playing with it. I've had trouble finding a decent tcl
> syntax summary, but its not like I know m4 very well, either.

M4 is deviously simple. It's autoconf that makes M4 seem difficult and
arcane.

<snip>
> I've just been playing around with it in a stub project, trying to see
> if it can do the lua header file discovery that every lua binding so
> annoyingly needs to do. Result is here:
> 
> https://github.com/sam-github/udns-lua/blob/master/auto.def
> 

The better alternative to autoconf is usually nothing, IMO.

For example, your include script is pretty trivial to do with the shell.
Unlike the 1980s and 1990s, Unix environments are significanly more
homogenous. There're very few headaches supporting the *BSDs and Linux. And
if you rigorously stick to POSIX then scripts almost always work elsewhere.
Most of the headaches I've had turned out to be my non-POSIX compliant
scripts.

Predefined CPP macros can handle most feature discovery tasks, and it's far
easier for others to contribute, and for you to integrate, experiential
knowledge. See, e.g.

	http://sourceforge.net/apps/mediawiki/predef/index.php?title=Main_Page

(I realize feature probing is preferable to version testing, but not at any
cost. And for those cases where it's clearly preferable it's fairly easy to
generate code from probes using Make.)

More importantly, sometimes it's best to just require the user to provide a
parameter. The infrastructure to do this automagically seems to get in the
way more often than it helps, especially for oddball cases, which ironically
is really the selling point** of using these tools. For example, I keep my
Lua headers under include/lua/5.?, similar to module paths and as god
intended. So your autosetup script would appear to fail in that case, plus
in other more common cases, like /opt or using separate project dirs under
/usr/local, like in the old Slackware days.

Autoconf may have given M4 a bad name, but there's nothing wrong with
multistage source generation, IMHO.

Finally, if you're trying to be portable to Windows then you're already
doomed to a fate worse than death, so the fact that the above points fail is
hardly consequential ;)


** That's the main selling point to the users. Distributions like them
because they tend to prevent the user from screwing up cross-compiling.
OTOH, if the build is relatively simple then it should be relatively simple
for the porter to fix. And the less stuff your build does to introspect the
environment, the fewer issues there'll be to fix in the first place.