[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