id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	difficulty	ghcversion	platform
458	inconsistent use of CPPFLAGS, LDFLAGS etc with build-type Configure	duncan		"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."	defect	new	high	Cabal-1.8	Cabal library	1.2.3.0	normal				normal	6.8.3