On Tue, 2005-08-30 at 00:41 -0400, Seth Kurtzberg wrote:
I'd have to turn the question around. In several major projects, I've never come across a situation where any of the autoconf hacks are necessary. I wouldn't reinvent autoconf. If I needed it, I would use it. I just have never needed it.
The problem with autoconf is that you have no idea, watching it run, which of the many things it tests are actually used. It does all the same tests for all programs.
I did apply a tool to two large projects that automatically generated autoconf support. It worked fine, but then since the code compiled just fine without it, that doesn't really show anything one way or the other.
Sounds like you were just using a boilerplate configure.ac file with some "standard" set of useful tests that someone had thoguht up once (or grown over time from experience in other projects). I work on a Haskell project that uses autoconf and automake. We started with an essentially empty configure.ac file. We have added tests whenever we found they were necessary. For example to test for minimum versions of ghc and other build tools and for the appropriate C compiler flags for some C libraries. We've also had to add and fix things when compiling on new platforms (which now include Linux, Windows, Mac OS X, FreeBSD, OpenBSD, Solaris). (The configure script works fine on Windows but obviously only with MinGW installed.) So everything in our configure script has a purpose (on one platform or another). Duncan