[Hackage] #458: inconsistent use of CPPFLAGS, LDFLAGS etc with build-type Configure

[Hackage]

#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 <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.

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/458>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects