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?"
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.
Maybe, but I often find as a user when trying to compile a package that has a .pc pkg-config file requirement for another package that that other package often forgets to leave it's .pc file around.
.pc files, meaning that even though I had the development libraries, Evo couldn't find them.
For instance, when compiling Evo from fresh source on a version of SuSE awhile back, I installed the various -devel RPMs that were required and yet those -devel RPMs left out their
Not saying pkg-config may not be useful, but it needs to be standardized on like autoconf used to be before it becomes truly useful to the power user.
Personally, I don't care which is used (pkg-config or a fixed autoconf) so long as it works well with others and is consistent.
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
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.
I took a quick look at pmk a while back. I got as far as this FAQ entry:
7. Why not supporting cygwin?
Because cygwin is not handling executable files as it should. It is absurd to have to take care about a trailing'.exe' under a Unix-like environment.
Absurd it may be, but Windows is the most popular platform out there and refusing to support it because it's too icky is just plain dumb. They've refused to make pmk useful enough to actually be valuable to me, so I haven't bothered using it for anything.
C code is more portable than any other language.
I speak from experience, having taken many odd projects and tried to get them to work on some even odder platforms. If you are writing code that needs to be widely used, say it implements a protocol or parses a file format you hope to be standard, C is your only choice.
If you are writing in perl or python, you are doing so because it is easier for you as the developer, not because it's easier or better for the person running it. In that case, one of two things must be true: You are very very important, and your convience can't be impinged upon at the expense of others; or, the code is very unimportant, so spending effort to allow other people to use it is a waste.
Guess what the case is for your code ?
Yours is a rather myopic and provincial view of the problem, IMHO. The autotools are a necessary evil when one has more dependencies than just ISO C. What versions of libraries are installed? What odd bugs must I work around? Where are the headers for package foo located on this system? What compiler options should I pass?
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.
What do the standards say about which version of libjpeg is installed and where its headers are? What about the version of Gnome? What if I want to support both Gnome and KDE if they are available? How do I determine that with Make?
I don't think you fully grasp the problems that the autotools actually do solve for developers.
the growth in cynicism and rebellion has not been without cause
Most software projects don't do more than the following:
:)
- compile programs into libraries and executables
- install executables, libraries, configuration and data files
Knowing the fact that there is no standard for shared libraries support the few lines you wrote are already a nightmare
Damien