Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
Programming

Journal krow's Journal: AutoConf Sucks 7

Journal by krow

I really hate autoconf. Its cryptic, it is a pain in the ass to use, and the only thing its got going for it is that the open source movement uses it like a bunch of lemmings.
I have went to the trouble before to make use of it. I found nothing of value from the experience other then a reminder of what it was like to write code ten or so years ago. Autoconf requires too many steps, its maintenance is high, and finding rule-sets that you need normally involves finding another project (yes I am aware of the archive) and looking to see how they did it. Who really wants to deal with M4 anymore?
What I have in mind is something a bit different. Lets put rule-sets in CPAN (yeah, I know, Perl, boo-hiss, whatever) and create an interface that builds your configure script by asking you a few questions. It should be able to pull whatever modules it needs from CPAN and then bundle them with your application so that it is portable. Have the configure script then generate make files.
Just imagine running a configure script where you will always see the same options. Perl is everywhere. Java may have Sun's marketing behind it, but Perl is the one language that is everywhere and comes on just about everything (and even Microsoft doesn't seem to have a problem with it, I have MS employees in my Perl classes at the University of Washington all of the time).
Autoconf has got to go, its time was nearly a decade ago. There is no reason to keep ourselves tied into this piece of legacy.

This discussion has been archived. No new comments can be posted.

AutoConf Sucks More

AutoConf Sucks

Comments Filter:
  • I've never had the displeasure to actually use autoconf before (I was scared away from doing anything complex in Linux because of it's obvious complexity), but it's definitely not the only sub-par GNU tool. I'm taking a C++ course at a highly regarded university right now, and we are forced to use gdb because it is Free, despite the fact that even the professor acknowledges it's innumerable flaws when working with code compiled from C++.
    • to clarify my parenthetical statement, I mean that what I stood to gain from using autoconf outweighed the time I'd have to spend reading documentation for a thousand useless steps and boring myself to death in the process.
  • Who really wants to deal with M4 anymore?
    And you would rather use what?
    Lets put rule-sets in CPAN
    Why there?
    create an interface that builds your configure script by asking you a few questions.
    This isn't a suggestion to change Autoconf; it's a suggestion to add a layer (conceptually) above Autoconf. Try to keep things straight.
    It should be able to pull whatever modules it needs from CPAN and then bundle them with your application so that it is portable.
    This is how Autoconf (with aclocal from Automake) works, except that modules are pulled off your computer, not off an internet site. So, again, all you're proposing is an additional (somewhat orthogonal) step be automated, in addition to what Autoconf provides.
    Have the configure script then generate make files.
    Um, this is what Autoconf already does.
    Just imagine running a configure script where you will always see the same options.
    I'm confused: what does this mean? Do you mean the command line options to ./configure? Those are already standardised.

    So, what I can parse of your complaint is really a request for another auto-tool. That wouldn't need to replace Autoconf any more than Automake or Autoheader does.
    • I would rather deal with perl or python, M4 is just nasty. It has never been that much fun to read and finding people who know it well is rare. If you go with Perl, CPAN is the logical place to find packages.

      I would never ever suggest have perl or python spit out autoconf crap. That just adds an additional layer that is not needed.

      No more tools to build auto-m4 files, just stop using it completely.

Slashdot Top Deals

MSDOS is not dead, it just smells that way. -- Henry Spencer

Close