[Hackage] #532: libraries and include checks can be highly misleading

[Hackage]

#532: libraries and include checks can be highly misleading
----------------------------+-----------------------------------------------
  Reporter:  guest          |        Owner:  kmcallister    
      Type:  defect         |       Status:  closed         
  Priority:  normal         |    Milestone:  Cabal-1.8      
 Component:  Cabal library  |      Version:  1.6.0.2        
  Severity:  normal         |   Resolution:  fixed          
  Keywords:                 |   Difficulty:  easy (<4 hours)
Ghcversion:                 |     Platform:                 
----------------------------+-----------------------------------------------
Changes (by duncan):

  * status:  assigned => closed
  * resolution:  => fixed


Comment:

 Thanks! I've applied this and extended it so that we also check compiling
 headers.

 For example for a header with wrong C syntax we get:

 {{{
 Configuring foo-1.0...
 setup: Bad header file: error.h
 The header file contains a compile error. You can re-run configure with
 the
 verbosity flag -v3 to see the error messages from the C compiler.
 }}}

 Where as if the header has a pre-processing error (eg `#include
 "missing.h"`) then we get:

 {{{
 Configuring foo-1.0...
 setup: Missing dependency on a foreign library:
 * Missing (or bad) header file: error.h
 This problem can usually be solved by installing the system package that
 provides this library (you may need the "-dev" version). If the library is
 already installed but in a non-standard location then you can use the
 flags
 --extra-include-dirs= and --extra-lib-dirs= to specify where it is.
 If the header file does exist, it may contain errors that are caught by
 the C
 compiler at the preprocessing stage. In this case you can re-run configure
 with the verbosity flag -v3 to see the error messages.
 }}}

 Patches applied:

 {{{
 Fri Apr  9 03:25:43 BST 2010  mcallister.keegan at gmail.com
   * better error messages for erroneous local C headers
   Addresses the issue in tickets #532, #648.
   When the all-together test of C libraries and headers fails, use only
 the
   preprocessor to probe the headers individually.  If they all check out,
   give a more equivocal error message and suggest -v3.

 Thu Apr 15 07:24:01 BST 2010  Duncan Coutts <duncan at haskell.org>
   * Also check compiling C headers at configure-time
   So we now both check if the headers can be pre-processed and separately
   if they can be compiled. If it fails the pre-processing check then it
   is usually (but not always) a missing header. If it fails to compile
   then it is definately borked, not missing. Error messages reflect this.
 }}}

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