Skip to content

cabal should handle missing build-depends better #469

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bos opened this issue May 24, 2012 · 1 comment
Closed

cabal should handle missing build-depends better #469

bos opened this issue May 24, 2012 · 1 comment

Comments

@bos
Copy link
Contributor

bos commented May 24, 2012

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

@tibbe
Copy link
Member

tibbe commented Jan 16, 2014

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 as completed Jan 16, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants