finding the dependecies of cabal packages

[Isaac Jones]

Brian Smith <brianlsmith at gmail.com> writes:

> On 7/29/05, Isaac Jones <ijones at syntaxpolice.org> wrote:
>> Brian Smith <brianlsmith at gmail.com> writes:
>> > (one of which I am working on).
>> 
>> Can you tell me more about the tool you're working on?
>
> Well, right now it is just a couple of really simple tools. 

(snip description of cool tools)

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

(snip)

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
necessary).

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

peace,

  isaac