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?"
Re:QMake (Score:3, Informative)
Two suggestions: (Score:3, Informative)
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.
Two awful suggestions (Score:5, Informative)
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.
Re:mod article up! (Score:5, Informative)
pkg-config provides you with compiler/linker/preprocessor flags for
compiling a program that uses various libraries.
Now, if only all libraries provided a
Try PMK, for example (Score:5, Informative)
You can find it at pmk.sourceforge.net [sourceforge.net]
Or else, you can have a look at A-A-P [a-a-p.org], by nobody else than Bram Moolenaar, the author of the One True Editor, a.k.a. ViM :-)
There is also Package-framework [freshmeat.net], by Tom Lord, the author of the infamous Arch [gnuarch.org] 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...
Re:QMake (Score:1, Informative)
not entirely sure why this got marked as a troll
Because QMake is free. I couldn't find any comment by the FSF about QMake, and it's dual licensed under exactly the same terms as Qt itself. From the FSF website:
Simply suggesting QMake wouldn't have been a troll, of course, but I assumed someone else would repost without the misinformation.
Re:Mod parent up! (Score:3, Informative)
well that's actually your distro's fault. And yes binary distro's suck at providing headers and other -config and
source distro's like Lunar-linux [lunar-linux.org] provide a wonderful rich platform with all of these -dev stuff installed by default and the way the developer has meant it. These source distros are excellent for developers.
Re:Mod parent up! (Score:3, Informative)
As somone who works on an open-source project that requires evolution-devel to compile, let me say that I am well aware of that problem. When GNOME went over to pkgconfig, many distros took a while to build their -devel packages with the .pc files.
That being said, I agree with the parent post - pkgconfig goes a long way toward solving problems with automake and autoconf. Everything in GNOME now uses it, so setting up the build environment for anything that depends on GNOME libraries is much, much easier. Hopefully other projects that provide libraries will follow in GNOME's footsteps.
Re:Solution to the Problem (Score:3, Informative)
But more importantly, if you're writing application
code using a system call layer, you've already lost
the game.
Re:Solution to the Problem (Score:3, Informative)
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
Re:more general question (Score:2, Informative)
autoconf has two purposes:
Converting from a plain Makefile to configure.in+Makefile.in is straightforward if your Makefile already uses variables for binaries and directories.
The main reason to use autoconf is the second point above; when you write code that uses system calls (eg read(2), write(2)) and not libc calls (eg fread(3C), fwrite(3C)), that differ between operating systems (eg BSD vs SysV vs POSIX), and need to detect which taste you have.
To answer your questions: autoconf is something I hook in when: