#458: inconsistent use of CPPFLAGS, LDFLAGS etc with build-type Configure
----------------------------+-----------------------------------------------
Reporter: duncan | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: Cabal library | Version: 1.2.3.0
Severity: normal | Keywords:
Difficulty: normal | Ghcversion: 6.8.3
Platform: |
----------------------------+-----------------------------------------------
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