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.
These are both sort of combined configuration and build systems (which is the way it should be IMHO). Scons requires Python (>=1.5.2, IIRC), so it is as "only" as portable as Python itself (which is to say "very") while cmake doesn't require anything except a C++ compiler. The actual "language" in Scons is just regular python while cmake uses a hideous custom language.
HAND.
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
> Is there something else out there that is as
> portable as autoconf to use instead?
Yeah. It's called GNU Make.
Seriously, if you write your makefiles and your
code in a responsibly portable manner, there's
absolutely no reason for autoconf or automake.
And it's not hard. I've done it repeatedly.
The auto* tools are an antipattern virus.
-I like my women like I like my tea: green-
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.
Babies are cute because they have to be.
Perl doesn't use autoconf. It does have script that sort of mimics autoconf, but isn't. Also most Perl extensions use `perl Makefile.pl` to configure themselves.
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.
no flame-bait i swear.
even tho 'write once debug everywhere' makes a great bumper sticker. it doesn't mean it is true. seriously, java is a good answer here.
... Those who do not understand autoconf are doomed to reinvent it. Poorly.
What kind of ${CRAP} are you writing that need ${YOURLANGSUCKS} anyway?
${MYLANGROXORS}
${FSCKYOU}
Case in point: I wanted to compile cairo on my Mandrake 9.1 system. I couldn't until I edited the autoconf file to remove "new commands" and added phony files to make pkgconfig happy. Then it compiled just fine and worked. I tried to compile the demos and was completely frustrated and eventually hand-wrote a trivial makefile and they all compiled just fine and worked (except for the GTK one...). I am now trying to compile the "Glitz" OpenGL backend, and I am running into the same troubles: I can't prove it yet, but I strongly suspect it will compile just fine on my machine, if I can just get around the mysteries and complaints of autoconf/automake/pkgconfig, probably by wasting a great deal of time and divining the basic, and probably simple, Makefile that would compile it.
The incredibly frustrating, and dare I say stupid thing is that the only thing I need to "update" on my machine is the damn autoconf tools! I actually have all the libraries and headers these things need. That is completely backwards! In fact due to autoconf they have pretty much said "this only compiles on the very newest experimental Linux system". Well in that case, you have eliminated the need for "autoconf" and you could send out Makefiles that work only on a new Linux system. That would probably be easier for somebody like me to edit and get working on an older system.
When you do try to fix this, you run into the horrifyingly bad syntax and rules of M4 and GMake. Supposedly this is because they want to be back-compatable and run on older systems. But they lie when they freely add new "autoconf" commands so that the newest version is needed. Why not scrap the whole thing and try a modern syntax?
My proposed solution: make ONE compiled program that does "configure" and "make" and "make depend" (and "install" and "uninstall" and "clean" and "dist" and all the other special-cased targets...). This program can use the existing automake/conf stuff so it can be compiled for multiple platforms. The program then reads one file, in editable text (no XML, and it should be trivial to add/remove a source file by adding/deleting a line). This file should be parsed in a procedural way, with "if" and "for" statements and functions (ie it is perl or something) and the result should be the dependencies tree and it can then run the programs (the result is extremely static and has actual filenames and commands, not templates or "rules"). Make it really easy to add and remove switches to the compiler. Make it save user answers to questions in a file so it can provide those answers again, and make a gui program that provides panels and checkboxes to change those user answers. Make it automatically check for dependencies in any C style source files by looking for "#include" without running the compiler, and save the results in a binary database with date stamps so it can run this instantly as needed. Any package dependenciies should be checked with "if" statements in the file, the program would have enough commands to do typical file system things like look for files or grep a file for something, and it is then trivial to write a file that checks for something in multiple places by using "if-else" statements.
I think you are trying the fix the problem on the wrong level.
There is nothing wrong with autoconf, and there is nothing wrong with new releases of software depending on the latest {autoconf|make|libc|lib|.*} whatsoever.
Take gentoo for example. After installing a minimal OS i can type emerge gnome and it will pull roughly 200 packages and compile them all cleanly. I honestly don't have any idea which of those 200 unrelated projects require which version of autoconf or whatever. Gentoo knows and deals with it by figuring out which is the latest autoconf required and getting this early on. As soon as you have infrastructure which does the dependecy resolution for you the problem evaporates.
That beeing said, my gentoo servers pull a new autoconf version about once a month for some random unrelated update. Thats really a bit excessive.
...is to use a language that's not going to get bogged down in the mess of portability. Java's a good example in theory but in practice is known to be somewhat brittle. Python/Perl/Mozilla seem to be a much better example in practice.
This, of course, limits you to systems on which the language has been implemented but it allows you to push the burden of portability onto somebody else.
my sig's at the bottom of the page.
Surprised that no one has mentioned 'smake'
Does anyone have a summary of the differences of all the various *makes?
to those who have some decent autoconf kung-fu:
after you get the hang of it, is it comfortable enough to use with all your building? or is something you add on at the end when app/project is ready for export?
I'm good enough at makefiles to make them pretty portable (i.e. it'll work on the 2-3 platforms I really care about at the time), and just have never bit the bullet and learned use autconf.
still, if I download something, and install procedure is anything besides "./configure; make; make install", I consider it a significant (though not 100% reliable) warning sign that I just downloaded crap.
"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.
A new program: autoconfconf
I am struck by the recursive nature of the situation.
Unknown host pong.
Another "-1 flamebait" by an idiot moderator who fails to understand how a computer works. Continue like this and all the world will be able to see the worthlessness of the Linux culture. Twats who think they can code but can't.
Consider this numbnuts, the BSD world manages without autoconf but the kiddie, wannabee Linux coders need hopeless tools to massage their ego.
Yes. Autoconf. The only GNU tool that is completely superfluous in a world of grown up programmers.
Look dumbass, your situation has nothing to do with what we are talking about.
If you have control over the group enough to mandate a specific version of autotools, why not just mandate a specific development platform, and then you can just use Makefiles or shell scripts or whatever ? Chances are, you guys DID mandate a specific development setup. So what was the point of autotools ?
Frequently you'll see statements like this in the INSTALL documentation of an application: "I've tested this on the following OSes: Linux (Fedora Core 1), Solaris 9 (SPARC, not x86), OpenBSD, and Plan 9. I've had reports that it works on HP-UX and AIX 5L. If you get it working on UNICOS (and can let me know about it) drop me a line with your patches."
This is perfectly sensible. Heck, its even quite common to have multiple versions of autotools installed to deal with all of the build dependencies one has. (I have 3 automake versions installed on the workstation I now write from.) Nothing wrong with that, really.
I think the story submitter may think it's a problem to have multiple autotool versions installed, but I don't think he knows what the problem really is. Perl doesn't use the autotools, and if Cray want's to help support its users, it could provide a UNICOS build system for OSS developers to test on like IBM does/did with AIX 5L.
the growth in cynicism and rebellion has not been without cause
Autoconf is ok, but it should be designed with it's own versioning schema on mind. To avoid nasty incompatible hacks in future. That future is now. But in software, everything is fixable, just someone must care about it. Anybody volunteers instead of slashdot ranting? Yes, I can hear you: you just don't like this m4 stuff, sorry.
There you are, staring at me again.
One word, standards.
What is needed is a *standard* build environment. If software is written to compile in these standard environments then the configuration problem gets pushed down to the construction of the build environment.
The problem is that lots of developers use autoconf as their build environment. Rather developers should use tools like pkg-config, gcc, gnu make, and ocamlfind. Then only these tools need to be ported to weird operating systems then everything else gets ported for free.
Most software projects don't do more than the following:
- compile programs into libraries and executables
- install executables, libraries, configuration and data files
For the first part you need to demand a build environment. Time should be spent porting build environment, not individual packages. For the second you need to build a suitable package spec --- be that debain, rpm, godi or whatever.
Silly me, deleting that autoconf/automake mess...
Rather than a simple non-recursive make system,
you'd like to have a 100% larger package full
of giant unreadable shell scripts and gibberish.
Would this make you happy?
echo '#!/bin/true' > configure
chmod 755 configure