Re: autotools alternatives, is anybody using autosetup?

[William Ahern <william@...>]

On Wed, Jul 18, 2012 at 11:49:15AM -0700, Sam Roberts wrote:
> > Supporting all of those platforms (including kqueue/epoll/completion ports)
> > in portable source code requires no support from the build system
> ^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Portable close-to-ansi-or-posix C src, like lua's, or your dns.c
> requires only to know how to call cc, but those aren't the cases I'm
> interested in. I'm interested in code that is not so trivially
> portable.

Therein lies much of the problem. Portability is often an after thought. For
example, people say, "I want do to XYZ". So they implement XYZ in Linux.
Then they tack on support for FreeBSD. Windows. Etc. It becomes a mess, even
if at the outset they intended to make it portable.

If they stood back and thought carefully about portability ahead of time,
they may have structured their project differently; approached the
implementation from a different direction; move a particular element up or
down the abstraction stack.

Instead, they wind up with a mess of problems and lean on the build system
to help solve them.

Example: asynchronous I/O. Windows and Unix use completely different
approaches. The primitives they expose, and the assumptions they make, are
completely at odds. Something like libevent is too low on that stack, which
makes it needlessly messy and confusing to use. libevent ends up with the
worst of both worlds and none of the redeeming qualities of either. And it's
Windows build is perennially broke, just like for most FOSS projects which
try to provide seamless POSIX and Windows support.

Out-of-the-box portability across disparate systems is rarely worth the time
and effort; it's a tarpit. Most projects which try it fail. Ultimately
support still requires user or developer intervention, so the effort in
automation was a complete wash. Time is better spent making it easier to
port--that is, as an active exercise.

> > whatsoever. The makefile's only job is to figure out how to invoke the
> > compiler and linker properly.
> 
> I see no sign that of support for epoll in the socket code in your
> libdns/contrib/ directory.

It's in the cqueues/ projects, about two hundred lines in the middle of the
Lua module cqueues.c.

> Also, avoiding support in your build system for finding dependencies
> by just including the dependencies in your project is certainly one
> way to go, but its not what I want to do.

Most of my code gets put into appliances and cloud environments. It gets
used _because_ it's easy to integrate into a project and tweak and modify.
And most of all, because it lacks dependencies. Dependencies cause nothing
but headaches. That's why so many commercial products have so many
vulnerabilities; updating dependencies is a nightmare. Merely making
something into a library does not solve that problem, and in fact can make
it worse because it turns the library into more of a black box, making it
seem more risky to swap out for a newer version. And if multiple components
depend on the same library, it's an all-or-nothing proposition, making it
less likely it'll get updated regularly. Adding library versioning into the
mix creates even more uncertainty; or at best puts you back to square 1, but
with a plethora of confusing libraries and headers.

The key characteristic that makes developer's lives easier is simplicity and
isolation. That's different than a black box. A black box says, "Do not
enter." Isolation means, "Play with me, you're not going to break anything."

I'm not saying installed libraries are bad. I'm just saying they're over
used, and used prematurely. Something that works well for libc or openssl is
not necessarily best for project foo.

A great counterexample is Lua. I really wish Lua had a more dependable
installation where Lua 5.1 and Lua 5.2 could sit side-by-side. But Lua
succeeded partly because it didn't try to solve this early on. It's only
after becoming successful that this was something that needed (needs) to be
addressed.