Skip to content


Subversion checkout URL

You can clone with
Download ZIP


cabal should handle missing build-depends better #469

bos opened this Issue · 1 comment

2 participants


(Imported from Trac #476, reported by @dcoutts on 2009-01-24)

It is a common complaint that missing build-depends causes unfriendly error messages.

For example 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...
Could not find module `Data.Map':
it is a member of package containers-, 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.


I don't think we're going in this direction anymore. We really need to know all the build dependencies if we're going to have hermetic builds. Open if you disagree.

@tibbe tibbe closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.