Nice. So I suppose the --simple-output flag works with it?
yes, it is just like 'list package', only it matches on
exposedModules rather than package id.
note: if you apply the patch, you will want to add find-module
to 'usageHeader' as well - seems i missed that.
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)
what you're really saying is that you'd like to relegate ghc-pkg
to a format conversion and do all the work in cabal. is it then
still sensible to have two separate tools, or should cabal take
over completely?
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)
we had a discussion about ghci vs cabal a while back:
http://www.haskell.org/pipermail/glasgow-haskell-users/2006-November/011554.html
and the topic keeps coming up in different contexts:
http://www.haskell.org/pipermail/glasgow-haskell-users/2007-February/012035.html
it took me a while to find these two again - perhaps your
cabal ticket is the place to keep these urls?
in current ghc head, there are several related ghci commands:
- ':show modules' (currently loaded modules)
- ':show packages' (package options + packages loaded)
- ':set' (now shows dynamic flag settings)
so you could load your main module into ghci, let it figure out
the module dependencies and packages, and use those
commands to contribute to an initial cabal file. you'd still need
to eliminate non-exposed modules and implicit dependencies
in packages, as well as flags that are at default settings.
that leaves other settings, like paths, which brings us back
to the earlier question and emails:
for any non-trivial project depending on non-standard
settings, shouldn't ghci work from a cabal file, or ghci
be started by cabal, or ghci and cabal collaborate, to
record those settings from the start and uniformly?
it makes no sense to re-enter .cabal settings in ghci just
because it can't load .cabal files, and it makes no sense
to write .cabal files from scratch when you've already
constructed a workable ghci session for your project.
the solution i've in mind is something like the ability
to import and export ghci sessions as .cabal files.
enabling ghci to explain all its session settings is one
way to get there, and since ghci is currently my main
interface to haskell code, i tend to add to that path. i
just patched ghc-pkg because it seemed sensible and
simple, but i also have a patch to make ':info <module>'
work in ghci.
do you have a specification of what cabal needs from
an implementation, how it would like to query for that
information, and an idea of how ghc, hugs, nhc, etc.
would implement that spec?
for ghc, one might be tempted to ask for an augmented
-M, but the prevalence of hugs and ghci seems to suggest
an "import/export session as .cabal" route as necessary,
if not sufficient. then there's nhc, which left dependency
chasing to a separate nhc-make tool (wasn't that one
of the starting points for cabal?), and i don't know about
the other implementations.
claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
