On Fri, 2007-11-09 at 16:43 +0000, Claus Reinke wrote:
> - the ticket asks for a module2package lookup in ghc-pkg
>     (this would be useful to have in cabal, as well)
> 
>   - we can now ask which packages expose a module we need,
>     eg, when preparing a cabal file or when getting errors
>     after package reorganisations:
> 
>     $ ./ghc-pkg-inplace find-module Var
>     c:/fptools/ghc/driver/package.conf.inplace:
>         (ghc-6.9.20071106)
> 
>     $ ./ghc-pkg-inplace find-module Data.Sequence
>     c:/fptools/ghc/driver/package.conf.inplace:
>         containers-0.1
> 
>   - implemented as a minor variation on listPackages
> 
>   (as usual, it would be useful if one could combine
>   multiple queries into one)

Nice. So I suppose the --simple-output flag works with it?

The solution we were thinking of for cabal though would be for Cabal to
ask ghc-pkg for all of its information and then Cabal can perform
whatever queries it needs rather than making lots of calls to ghc-pkg.
http://hackage.haskell.org/trac/ghc/ticket/1839
Ticket #1839 (need ghc-pkg dump feature)

If you're hacking on ghc-pkg maybe you'd be interested in adding that
feature.

As you suggest it would be great for Cabal to tell you that you're
missing package dependencies rather than letting ghc stumble over the
problem with a correspondingly more confusing error message. Indeed we
could do nice things like building without needing a .cabal file or
automatically generating a minimal .cabal file by inspecting local files
and the package dbs.
http://hackage.haskell.org/trac/hackage/ticket/171
Ticket #171 (Add command to automagically create an initial cabal
package)

Duncan

_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to