finding the dependecies of cabal packages
simonmar at microsoft.com
Mon Aug 1 05:24:03 EDT 2005
On 29 July 2005 23:19, Isaac Jones wrote:
> Brian Smith <brianlsmith at gmail.com> writes:
>> I think what VHS.NET does--and what I am/was planning to do--is use
>> Cabal files as projects, but reimplement Distribution.Simple.Build
>> et. al. to work in an better in an "interactive" GUI environment
>> than the current system, which is batch-compile oriented. In
>> particular, VHS.NET and maybe my tool will use the GHC API
>> For example, using the GHC API I can do dependency analysis that will
>> allow me to say "build just this one source file because that other
>> source file changed." But, Cabal always restarts dependency analysis
>> over at the root modules, which make it too slow for interactive use.
> Why not work to speed up Cabal's execution time rather than
> reimplement so much from scratch, and in a compiler-dependent way?
> There's nothing inherent about Cabal's interface that makes it do
> things in a batch, or slows compilation time. It uses GHC's --make
> flag (though it always relinks the library, which is not always
> If your tool is written in Haskell, and could be made compiler
> agnostic, perhaps we could add such features to cabal itself... maybe
> we could have a "./setup build --continuous" which emits status to a
> file or uses a socket interface or something in order to communicate
> w/ eclipse, VS, and your tool, since they often want the same kind of
Brian is talking about having access to the same facilities that Visual
Haskell uses when editing a Cabal project in the environment. For
example, when a source file is edited (without even being saved), we can
invoke the GHC API to re-typecheck it in the context of the rest of the
project, and ask GHC about the types of its identifiers.
This is an interactive application, and it needs a programmatic
interface so that state can be maintained between calls. A command-line
interface isn't the right thing here.
I suppose the question is whether there is a useful re-usable
abstraction that we can provide as part of the Cabal libraries.
Essentially, it would be an abstraction over the GHC API that
communicates the details of the program in terms of a
PackageDescription. Actually, this would make more sense as part of the
GHC API rather than part of Cabal (you don't want a dependency from
Cabal on the ghc package, but ghc already depends on Cabal).
Using this abstraction, we could construct "ghci --cabal" very easily.
Using it in Visual Haskell would be tricky, because I believe we have a
different internal representation of PackageDescription.
Brian - if you'd like to think about the API, I'll be happy to comment
More information about the Libraries