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

QMake

[rufus0815]

QMake (from Trolltech) is a possible replacement, though not free (according to the FSF)!

Re:QMake

[rufus0815]

AFAIK it still hasn't got a lot of features that automake has (specially the detection / configuration stuff - as you said correctly).
Never the less, it's easy for beginners, and it's cross-plattform!
So for posix developers it might be unsufficient - for Windoze developers (M$VC) it would be a great improvement (the way M$VC handles the project settings is horrific)!

You have been 's CONNED

[sofar]

SCons isn't the solution either. SCons relies way too heavily on python and doesn't make better distribution tarballs. Most developers using SCons rooll out horrible tarballs that cannot even detect the proper Python version! (blender!!!).

SCons makes you lazy, do the work, then your application builds BETTER on MORE platforms with autoconf

Mod parent up!

[sofar]

pkg-config singlehandedly is creating a sea of calm in autoconf land while still keeping the strength of autoconf. Take Xfce4 for instance. Within a relatively short timeframe this small group (4-5 devs) have written an entire framework that compiles on tens of platforms by using PKG_CONFIG extensively together with autoconf

Solution to the Problem

[aminorex]

> Is there something else out there that is as
> portable as autoconf to use instead?

Yeah. It's called GNU Make.

Seriously, if you write your makefiles and your
code in a responsibly portable manner, there's
absolutely no reason for autoconf or automake.
And it's not hard. I've done it repeatedly.
The auto* tools are an antipattern virus.

Well,if you've got to build software for Crays ...

[Anonymous Coward]

Chances are the other packages people here are talking about haven't ever been built on a cray, too. A Cray is not exactly common-place.

Usually, the simplest way to deal with broken scripts/automake/autoconf tests, is to use a better shell. Take the bash, tcsh, or whichever shell works on Unicos, and run your autoconf tests throught that. If you think you've found a problem in autoconf itself, run the regression test suite and submit a bug report.

A quick google search over the autoconf mailing list archive shows that there were 0 posts on Unicos in the last two years. So chances are, that any bugs in autoconf itself in the last two years have not been tested, or that it has no bugs on Unicos ;) I'd think that the autoconf developers would appreciate a good bug report, just like any other project would.

If your problem is autoconf's performance, then a) use a faster shell, b) use --cache-file, c) use ccache to run those myriads of little C tests faster. Or fix the tests in question.

A classic on slow platforms is the maximum shell length test. That one comes from libtool, not from autoconf. It's been vastly improved in libtool 1.5.6, for example. If your upstream doesn't use a recent version of libtool, convince them to do so. :)

I have a replacement

[Chemisor]

I was pretty fed up with autoconf myself, and wrote a little C app to emulate it. Initial ./configure time dropped to a second and reconfigure is instantaneous. I would recommend it for your simpler projects: bsconf.c [sourceforge.net] and bsconf.h [sourceforge.net], the latter being the configuration file.

Re:mod article up!

[Crayon Kid]

Which brings me to another issue: why isn't the output from 'configure --help' available in machine-readable form? Say, XML? This would help a lot with the creation of graphical configuration tools for source packages. AFAIK there are a couple of helper apps out there that do this, but they have to go through horrible hoops parsing the output from 'configure --help'.

Write portable code.

[V. Mole]

It's really not that hard. The autotools are crutch for people who can't be bothered to actually learn the C language and library, or the difference between POSIX and what their current environment provides. Go read #ifdef Considered Harmful [literateprogramming.com] (PDF) by Henry Spencer, about the right way to deal with portability problems, and notice that the whole approach of autoconf is wrong.

"checking for stdlib.h..." indeed. If you don't have an ISO-C environment, you're so screwed that there's nothing autoconf can do to save you: you don't know how the language works, so whether or not you're missing a few library functions isn't going to make any difference.

I once worked on a fairly large process control system, of which less than 1% was portability code. It ran on Solaris, AIX, HP-UX (this was pre-Linux). It also ran on VMS and WinNT. Most of the portability issues dealt with the entirely different models for process management and memory-mapped files, not with pipsqueek stuff like autoconf.

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.

As for the autotools proclaimed ability to port to systems you weren't planning for, that's so much BS. If the system is sufficiently different that ANSI C and POSIX aren't sufficient, then you're going to have to update your code anyway.

Replacing autoconf with some other crutch isn't going to help. Just ditch it entirely.

Re:Mod parent up!

[KewlPC]

Until a project decides not to put it's .pc files in the standard place. For instance, when installing Clanlib on my Gentoo system (using Portage, no less), the .pc files didn't get put in /usr/lib/pkgconfig (which is where pkg-config expects them to be on Gentoo).

Instead they got put in /usr/lib/clanlib-0.7.7, and when I tried to build a program that used pkg-config to find clanlib, the build broke. If I were a Linux newbie, I'd probably have just given up rather than try to find the .pc files that I knew were installed.

I really don't want to get into some kind of PKG_CONFIG=$PKG_CONFIG:/some/directory:/some/other /directory:/yet/another/directory mess.

Re:how about java?

[tradervik]

Indeed. We develop server-side code on Windows (2k and XP), and deploy on Linux, Windows, and Solaris. With three major products representing millions of lines of code developed over a period of approximately 6 years, we have never had a single instance of platform incompatibility.

Re:Mod parent up!

[elFarto the 2nd]

This is the one thing that bugs me about pkgconfig. I mean how hard can it be to add a --install option, allowing pkgconfig to choose where to place the .pc file.

Maybe I'll go make a patch...

Regards
elFarto