Slashdot Mirror
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?"
QMake (from Trolltech) is a possible replacement, though not free (according to the FSF)!
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.
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.
they may be a drop in replacement for developers, but for packagers and people trying to track changes and new versions, both cmake and scons (blender!) are horrible. They cost us (A group of 10 people working on a distro) enormous amount of extra time (blender's upgrade to
all in all autoconf maybe a problem for developers, but for packagers it is still *by* *far* the best.
SCons isn't the solution either. SCons relies way too heavily on python and doesn't make better distribution tarballs. Most developers using SCons rooll out horrible tarballs that cannot even detect the proper Python version! (blender!!!).
SCons makes you lazy, do the work, then your application builds BETTER on MORE platforms with autoconf
You can find it at pmk.sourceforge.net
Or else, you can have a look at A-A-P, by nobody else than Bram Moolenaar, the author of the One True Editor, a.k.a. ViM :-)
There is also Package-framework, by Tom Lord, the author of the infamous Arch SCM.
I was about to mention SCons, too, but other people already did (it always pay to check other comments just before posting, especially on /. :-)
To sum it up : there is no shortage of alternatives to the incredibly hairy Autoconf/Automake nightmare. The problem is, people are still using them for the very same reason they use CVS instead of Arch/Subversion, or Sendmail instead of Postfix/Exim : because they're considered ``standard'' tools, and people feel more comfortable with software they know to be used by plenty of other people (millions of programmers can't all be wrong. Can they ?). I really hope they'll stop making this kind of mistakes soon, so I won't need to curse them everytime I have to debug some Autoconf breakage...
Xenu brings order!
pkg-config singlehandedly is creating a sea of calm in autoconf land while still keeping the strength of autoconf. Take Xfce4 for instance. Within a relatively short timeframe this small group (4-5 devs) have written an entire framework that compiles on tens of platforms by using PKG_CONFIG extensively together with autoconf
Chances are the other packages people here are talking about haven't ever been built on a cray, too. A Cray is not exactly common-place.
;) I'd think that the autoconf developers would appreciate a good bug report, just like any other project would.
:)
Usually, the simplest way to deal with broken scripts/automake/autoconf tests, is to use a better shell. Take the bash, tcsh, or whichever shell works on Unicos, and run your autoconf tests throught that. If you think you've found a problem in autoconf itself, run the regression test suite and submit a bug report.
A quick google search over the autoconf mailing list archive shows that there were 0 posts on Unicos in the last two years. So chances are, that any bugs in autoconf itself in the last two years have not been tested, or that it has no bugs on Unicos
If your problem is autoconf's performance, then a) use a faster shell, b) use --cache-file, c) use ccache to run those myriads of little C tests faster. Or fix the tests in question.
A classic on slow platforms is the maximum shell length test. That one comes from libtool, not from autoconf. It's been vastly improved in libtool 1.5.6, for example. If your upstream doesn't use a recent version of libtool, convince them to do so.
I was pretty fed up with autoconf myself, and wrote a little C app to emulate it. Initial ./configure time dropped to a second and reconfigure is instantaneous. I would recommend it for your simpler projects:
bsconf.c
and
bsconf.h,
the latter being the configuration file.
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:
All of the above are easily detectable with autoconf.
I however agree with you that there's absolutely no need for automake.
... Those who do not understand autoconf are doomed to reinvent it. Poorly.
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.
What kind of ${CRAP} are you writing that need ${YOURLANGSUCKS} anyway?
${MYLANGROXORS}
${FSCKYOU}
"checking for stdlib.h..." indeed. If you don't have an ISO-C environment, you're so screwed that there's nothing autoconf can do to save you: you don't know how the language works, so whether or not you're missing a few library functions isn't going to make any difference.
I once worked on a fairly large process control system, of which less than 1% was portability code. It ran on Solaris, AIX, HP-UX (this was pre-Linux). It also ran on VMS and WinNT. Most of the portability issues dealt with the entirely different models for process management and memory-mapped files, not with pipsqueek stuff like autoconf.
It's real simple: you read the docs. You determine what the standard actually requires, not what your development system happens to do. And you program to that, then test.
As for the autotools proclaimed ability to port to systems you weren't planning for, that's so much BS. If the system is sufficiently different that ANSI C and POSIX aren't sufficient, then you're going to have to update your code anyway.
Replacing autoconf with some other crutch isn't going to help. Just ditch it entirely.
I had to anonymous answer you so I could mod parent up.
Of course thats what ifdef is for, but ifdef isn't dangling its always:
#ifdef SOMETHING
and where do you think the SOMETHING comes from for cases like:
* 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 ?
I'll tell you; auto-conf doe some checks, possibly test-compiles, basically discovers the local landscape and sets a LOAD OF PREPROCESSOR SYMBOLS (OK, and custom makefiles blah blah, what do you think holds the #def's anyway) and then compiles the code full of #IFDEF's
Sam