"#!..." (Re[2]: cabal configure screw-up)

Duncan Coutts duncan.coutts at worcester.oxford.ac.uk
Tue Aug 30 04:49:15 EDT 2005

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


More information about the Libraries mailing list