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

2 of 108 comments (clear)

  1. Re:problem inevitable by Anonymous Coward · · Score: -1, Troll
    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

    This is why I truly and honestly believe that Microsoft Windows is the best way to go. They only release a new version every few years and it is generally very good with backward compatibility. Plus they frown on compiling stuff from scratch unless you're a commercial company anyway so no nasty autoconf needed.

  2. Use the same versions by Anonymous Coward · · Score: -1, Troll

    Generally when I have worked on projects in the past where the GNU Autotools were used, all the developers were requires to use the same versions of these tools. Since end users don't need autoconf, etc. this wasn't really a problem. I agree that this isn't a perfect solution, but the benefits of using the Autotools outweighed the negatives of all developers needing the same version.