whatever format it likes. But we do need some info on the installed
packages. We can do that now by calling ghc-pkg list and ghc-pkg
describe on each one. ghc-pkg describe returns a standard format defined
in Distribution.InstalledPackageInfo in the Cabal library.
All we're asking for is a slightly faster way of doing that. When we
have 150 installed packages calling ghc-pkg 150 times will take three
and a half minutes (when I had 150 hackage packages installed I clocked
ghc-pkg at 1.5s to describe any package). Even if ghc-pkg were faster,
it's still just more convenient to do queries ourselves than by asking
ghc-pkg all the time.
if we can sort out how the '--bulk' query option i implemented can
fit in despite the regex dependency, you would have that option.
http://hackage.haskell.org/trac/ghc/ticket/1839#comment:3
but what then? do you dump, read, and parse all package databases
for all installed ghcs (not to mention other haskell implementations)
every time cabal is run? or do you store copies of all of them and keep
them up-to-date? do you replicate all the functionality of ghc-pkg,
ghc --make, hugs, nhc-make, ..?
As I see it, all of these cool features depend on Cabal being based on a
make-like system internally and doing dependency chasing itself. If you
follow cabal-devel you'll see we've started on some prototyping work in
that direction and we would welcome people to join in the fun.
i never understood how cabal came out without such a system
in the first place. but as it is now, i have to wonder: wouldn't it
be easier to specify what cabal needs and have ways to expose
the haskell implementation's dependency chasing results?
at what point does it become more useful to implement functionality
in cabal rather than augmenting what exists and having cabal as a
unifying interface? for everything beyond pure haskell import?
If Cabal can do dependency chasing then it can figure out the required
modules and packages. It could go further than what ghci can do by also
finding what pre-processors are necessary and the ultimate source files
for each module.
isn't that too optimistic? unless there is a specified path from
the Main module, say, any such auxiliaries would need to be
specified explicitly either way, just as the paths in which to
find them. and even if you have a Parser.hs pointing back to
a Parser.ly, you may end up with having to rename Parser.ly
so that cabal doesn't touch it.. ;-)
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?
We have some rough general ideas. Certainly a collection of
InstalledPackageInfo records is enough information. We need to be able
to do things like map module names to packages and possibly to
individual files to be able to track changes in installed packages which
might require a rebuild of the current code.
i don't think the cabal level has enough information to make
such decisions - if i empty all modules in a package, cabal
can't see the difference before calling the compiler; nor can
cabal see what dependencies were used to build a package,
let alone whether they are up to date. without such information,
cabal can only call the compiler and ask it to bring a target
up to date.
also, do you want --make-style (sources point to their
dependencies) or make-style (separate specification of
dependencies)?
it might help to specify all the possible links in the intended
dependency chain, such as:
- module A import B -> A.hs needs B.hs
- module A -- generated from A.ly -> A.hs needs A.ly
- module A -- generated from A.hsc -> A.hs needs A.hsc
- name:A; build-depends: B -> A.cabal needs B.cabal
..
and then to pin down how each of those is going to be
specified, and to check whether there is sufficient information
at the cabal level to make any decisions, and to find all
dependencies.
claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
