Slashdot Mirror

← Back to Stories (view on slashdot.org)

Alternatives to Autoconf?

Posted by Cliff on from the dodging-the-complexities dept.

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?"

4 of 108 comments (clear)

  1. Two awful suggestions by sofar · · Score: 4, 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 .33 took me a whole day to figure out, whereas before it only takes me 20 minutes to fully test a new blender version).

    all in all autoconf maybe a problem for developers, but for packagers it is still *by* *far* the best.

  2. Re:mod article up! by noselasd · · Score: 5, Informative

    Try pkg-config --list-all
    pkg-config provides you with compiler/linker/preprocessor flags for
    compiling a program that uses various libraries.
    Now, if only all libraries provided a .pc file..

  3. Try PMK, for example by wsapplegate · · Score: 5, Informative

    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!
  4. Re:Solution to the Problem by Anonymous Coward · · Score: 3, Informative

    I had to anonymous answer you so I could mod parent up.

    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