inconsistent use of CPPFLAGS, LDFLAGS etc with build-type Configure

[bos]

(Imported from Trac #458, reported by @dcoutts on 2009-01-16)

We have a mismatch between the cabal Setup scripts which ignore LDFLAGS etc and provide --extra-lib-dirs instead, and some ./configure scripts which grab the CCFLAGS etc and bung them into a .buildinfo file.

This is bad because it means --extra-lib-dirs does not work for those packages and it also means that those packages consult the CCFLAGS etc and others do not. It's quite an inconsistent user interface.

We should try to make it more consistent. One approach would be for cabal to consider the CCFLAGS etc, to combine them with the flags passed on the command line and those specified in the .cabal file. (We have code to analyse CC/LD/CPP flags and to split them up into the standard BuildInfo? fields.) Then for configure scripts we could pass the whole lot. The danger of course is that the configure scripts duplicate it all and put it into a .buildinfo file.

Another tempting option is to call configure with a clean environment so that it cannot pick up these vars. Unfortunately that might break some existing packages.

We should be careful with the use of these env vars though, because while it's fine to change the user interface to cabal-install, the interface to the Setup.hs is a machine interface and the more we require of it, the more has to be implemented by every different build system.

A case in point is the curl package. It has a .buildinfo file like:

cc-options: @CPPFLAGS@
ld-options: @LDFLAGS@

The ./configure script checks:

AC_TRY_CPP([#include <curl/curl.h>],,[no_curl=yes])

Which uses the CPPFLAGS.

So it's adding an extra package-specific user interface by consulting these environment variables. At the same time the configure script ignores the --extra-lib-dirs= and --extra-include-dirs= Setup.hs command line flags. This means that users doing what is advertised will find the package does not work. Indeed changing to build-type: Simple and deleting the configure script makes it work perfectly. So this mismatch is clearly harmful.

See also #262 which should make these checks redundant.

[bos]

(Imported comment by @dcoutts on 2009-01-16)

For a real world example see http://hpaste.org/13991

The user reported that setting build-type: Simple and using

runghc Setup configure --extra-include-dirs=/usr/local/include --extra-lib-dirs=/usr/local/lib

made the package work fine.

In addition, the user can make the above settings permanent in their ~/.cabal/config file and not have to worry about this again.

[bos]

(Imported comment by @dcoutts on 2009-01-16)

See also http://trac.haskell.org/haskell-platform/ticket/11

Perhaps we should be setting the C_INCLUDE_PATH and/or LIBRARY_PATH based on the include dirs etc from all the dependent packages (especially base, rts etc). That way we should be able to pick up GHC's mingw directory, and similarly for gmp etc on OSX.

[bos]

(Imported comment by @dcoutts on 2009-04-16)

See also #553 about always passing --prefix etc along to ./configure even when using the default prefix.