Alternatives to Autoconf?

Despairing Developer queries: "Once autoconf was a great way to make widely portable programs. But now when you have to spend more time sorting out incompatibilities between autoconf versions, breaking battles between autoconf compatibility wrappers and configure.in compatibility functions that tries to outsmart each other, and on top of that see the list of dependencies increase (it's not that fun to compile perl on unicos) and performance diving rapidly, what is your escape plan? Is there a drop in replacement for autoconf? Is there something else out there that is as portable as autoconf to use instead?"

Comments

mod article up!

[blackcoot]

i wish there was a way to moderate articles up, because you've hit on one of my major (*major*) pet psychotic hatreds regarding developing software. auto(conf|make) sucks badly. it's bearable if you're developing from scratch (not depending on other libraries) or require that your bundled versions of libraries be used. but when your software depends on, say, 123098123871237 other packages (i.e. you're writing for gnome or kde), you're boned.

unfortunately, there are no reasonable replacements that i know of, which is probably a testament to the nastiness inherent in solving this problem. a pity, really -- auto(conf|make) and company are a really good idea (in theory). unfortunately, there seems to be some really bad crack smoke involved in designing these tools. first (and probably foremost) in my mind is why isn't there a database of some sort which would at least allow the option of keeping track of which versions of what applications have been configured how and installed where.

problem inevitable

[fraccy]

I feel your pain, but this isn't just autoconf. Its a general theme of the way we compute. Version nightmares. I think the problem is unavoidable because of the way we currently compute: 1) Competition and the enormous diversity today will always leads to heterogenous systems, no matter how good their intentions initially 2) The semantics of software and its environment are not embedded in the data, which of course means when a version changes, something somewhere breaks, and someone somewhere has to fix it Theres only two solutions, either by decreasing diversity through standardisation (oh heck the version of that keeps changing too), or real autonomic computing operating at a higher level of abstraction. Roll on autonomic computing, real self-configuring and self-adapting systems. Until then, we can only attempt to minimise the problems, and can only ever solve them in a limited scope for a limited period of time.

Re:Solution to the Problem

[grubba]

So how do you portably detect which taste of system calls you have on the OS without autoconf, and without an explicit database OS <=> feature?

eg:

• Is your getservbyname_r OSF/1- or Solaris-style?
• Does your getspnam_r take 4 or 5 arguments?
• Does your struct hostent have the field h_addr_list?
• Are you on a Linux system with a broken <shed.h>?

All of the above are easily detectable with autoconf.

I however agree with you that there's absolutely no need for automake.

Hate to say it, but ...

[Russ Steffen]

... Those who do not understand autoconf are doomed to reinvent it. Poorly.

Re:Two suggestions:

[jrumney]

Using a Ruby based configuration makes sense if your project uses Ruby anyway, just as using Ant makes sense for Java projects, but for building standalone C/C++ projects non-standard build tools are just another dependancy that will ensure that noone will bother to use your project because you set the barriers too high. The benefit of autoconf/automake is that only the developers need to use it. End users run a pre-built configure script, which runs in /bin/sh.