On Fri, 2005-07-29 at 12:43 -0700, Isaac Jones wrote:
For example, an IDE might use the GHC API to implement an "incremental build" feature, which would rebuild projects upon detecting changes to the source files (like Eclipse does). Futhermore, it might want to provide context-sensitive features like autocomplete that Cabal doesn't provide, and that requires knowledge of all source code dependencies in the source code.
I don't understand what you mean; how does this involve the simple build system if you're using the GHC API?
I think the requirements of an IDE on a build system are probably even more extreme than what I've been banging on about - the needs of packaging systems. Packaging systems want quite a bit of flexibility and insight into the build but don't really care too much about many internals like whether it is incremental or monolithic. This provides flexibility by allowing multiple build systems to conform to the same Cabal interface. However an IDE wants even more. It wants to be able to rebuild individual files quickly (so dependency tracking is required and linear build scripts are out). It will want to provide a GUI interface for changing build system parameters (which means that the build system has to be declarative, not scripted). And no doubt there are other things too. The point is that fulfilling these requirements might be possible for some imagined future version of the "simple" build system, however if the Cabal interface is extended to stipulate these same features then it would exclude most other build system implementations. Duncan