Alternatives to Autoconf? 108
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?"
mod article up! (Score:5, Insightful)
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 (Score:5, Insightful)
Re:Mod parent up! (Score:2, Insightful)
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.
Re:Solution to the Problem (Score:5, Insightful)
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.
Hate to say it, but ... (Score:4, Insightful)
... Those who do not understand autoconf are doomed to reinvent it. Poorly.
Re:Two suggestions: (Score:4, Insightful)
Re:Try PMK, for example (Score:3, Insightful)
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.
Re:The only real way out... (Score:1, Insightful)
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 ?
Re:Write portable code. (Score:3, Insightful)
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.
Re:Autoconf is used too much (Score:1, Insightful)
- 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