[Hackage] #476: cabal should handle missing build-depends better

Hackage trac at galois.com
Sat Jan 24 10:13:08 EST 2009


#476: cabal should handle missing build-depends better
------------------------------+---------------------------------------------
  Reporter:  duncan           |        Owner:           
      Type:  enhancement      |       Status:  new      
  Priority:  normal           |    Milestone:  Cabal-2.0
 Component:  Cabal library    |      Version:  1.6.0.1  
  Severity:  normal           |     Keywords:           
Difficulty:  project(> week)  |   Ghcversion:           
  Platform:                   |  
------------------------------+---------------------------------------------
 It is a common complaint that missing `build-depends` causes unfriendly
 error messages.

 For example http://trevion.blogspot.com/2008/11/cabal-is-fine-piece-of-
 software.html writes

 {{{
 I noticed another nice Cabal feature upon first adding the line

 import qualified Data.Map as Map

 to my program. Of course, recompiling produced the message:

 Preprocessing executables for interpreter-0.1...
 Building interpreter-0.1...

 src/Core.hs:8:17:
    Could not find module `Data.Map':
      it is a member of package containers-0.1.0.2, which is hidden
 }}}

 The commentator notes:

 {{{
 But really, my favorite feature is highlighted by the GHC
 error message about not being able to find Data.Map. Of
 course, Data.Map is on my system – GHC’s even found it, and
 told me where it is. But Cabal’s made an important
 distinction: just because I have software installed in my
 development environment doesn’t mean I want to use it! Rather,
 Cabal’s started out by hiding all the Haskell libraries
 installed on my system. This helps me really appreciate the
 packaging system, as I get to individually add each package
 I’ve previously installed and then wish to use to my metadata
 file. Of course, keep in mind, this is a per-project effort!
 Even if I’ve used a library in one project, I might not want
 to use it in my other projects.
 }}}

 Which is of course right. It is rather annoying.

 For Cabal-2 we plan to track module dependencies directly rather than
 relying on `ghc --make`. In that case we have two options to improve the
 above situation. For quick and casual builds (perhaps not even using a
 .cabal file) we can just use the available packages and not complain. For
 packages that we expect to distribute we can either give warnings or
 errors about missing `build-depends`. In either case we can say exactly
 what is missing (not just the first) and we can make a reasonable
 suggestion about what version constraints to use.

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


More information about the cabal-devel mailing list