Re: finding the dependecies of cabal packages

Brian Smith writes:

On 7/29/05, Isaac Jones wrote:

...

Brian Smith 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