Re: autotools alternatives, is anybody using autosetup?

[William Ahern <william@...>]

On Tue, Jul 17, 2012 at 11:25:27AM -0700, Sam Roberts wrote:
> william@25thandclement.com wrote:
> 
> >>> The better alternative to autoconf is usually nothing, IMO.
> 
> Clearly, I don't agree, or I wouldn't be looking for one :-)
> 
> This makefile approach is crap:  https://github.com/sam-github/pcap-lua

That's not too bad. Obvious issues are that one shouldn't put an explicit
"/" after $(DESTDIR), and install is not a POSIX utility. It requires GNU
Make, but that's fair.

> It only supports two platforms, but not well, and I have to copy the
> boilerplate approach to all my projects, where they slowly
> desynchronize.

You also have to write different code for each project. I don't see what the
issue is.

The search for the perfect automated build system is a fool's errand, IMHO.
Your best bets are either autoconf (if you know it and don't care about the
versioning nightmare) or standard make and unix utilities. That is, of
course, my own opinion.

Some day I'd like to write a makefile translator which can convert certain
non-portable macro and conditional constructs between the various make
flavors. But I'll never pretend that it would be preferable than autoconf or
plain make for general usage. There are two customers, myself and the users
of my code. I may be comfortable with one approach, but third parties
generally expect either autoconf or plain Make. Use anything else and their
ability to fix build bugs or contribute patches drops dramatically.

> On Mon, Jul 16, 2012 at 10:26 PM, Coda Highland <chighland@gmail.com> wrote:
> > Would you consider LuaJIT to be a "trivial" case? It doesn't use
> > anything but straight-up "make".
> 
> Yes, I would. I just looked, and luajit appears to have only trivial
> dependencies: a C library and gcc. Most of its 600+ lines of src/Makefile
> is devoted to figuring out how to call gcc for the platforms it supports.

And how many lines of autoconf'd M4 and shell code would be required to
introspect this, or to declare it as an option through the build?

You have to compare apples to apples. And even if using autoconf or
something else required fewer lines of code, you have to offset it against
the hassle.

> I maintain libnet (but did not write it, or make its autoconf system), and
> system networking APIs vary enormously, I would describe it as
> non-trivial. auto* is mostly for testing existence of dependencies, when
> the mere fact that you are compiling on a platform is not sufficient to
> know if an optional dependency exists.
> 
> Also, if your platform support is wide, it can be better to declare what
> you want from a system, then try to exhaustively list for every supported
> system, whether you believe it does or does not have a particular
> facility.

I've written and maintained an asynchrounous sockets and stub/recursive DNS
library for several years. For cqueues I decided to make sure those source
files worked under Solaris, NetBSD, and FreeBSD (previously I only ever
wrote it for OS X, OpenBSD, and Linux). Lo-and-behold the entire thing
compiled just fine on all of those with very little effort. The only real
issue was my CPP-based byte ordering detection was wrong for my DNS packet
structure.

Supporting all of those platforms (including kqueue/epoll/completion ports)
in portable source code requires no support from the build system
whatsoever. The makefile's only job is to figure out how to invoke the
compiler and linker properly.

I see that libnet supports OSF/1 and Windows, and like I said before once
you step outside the modern world of POSIX things get really hairy. But in
those cases I _especially_ doubt that there'll be a satisfactory automated
build solution. Elbow grease and aspirin is about the only way to approach
it.