Duncan and others, I have some high-level thoughts: = Standalone Tool = Something I've talked about for a long time (and a few times tried to get someone to implement) is a kind of EDSL for Setup files so that people can replace Make more easily by using the Setup files, and this seems like it could be a good start. You could use Parsec as a model for building a little language for dependencies and actions for those dependencies. Make is a mess because it's really hard to build any kind of abstractions using it; the main thing it does for you is the Make algorithm you've shown here, and everything else is really hard. Haskell would be much better at this :) Cabal is getting more and more complex, and I think it would be good to consider how you might separate this from Cabal. Perhaps you could implement a make-a-like library that's pretty standalone, but would be designed for use by Cabal, and indeed, Cabal would probably use it internally, but it could also be used outside of the context of Cabal. = Pros & Cons of Cabal Complexity = I've tended to resist adding complexity like RPMs to Cabal because I tend to think that smaller, standalone tools that can be elegantly composed is better. The good part of composable standalone tools is that you can spread out the development effort among folks who are experts in their smaller tool. You also can keep Cabal from being so complicated that it's hard to bootstrap packages, and so that the changes between versions aren't as painful. The downside of keeping Cabal simple is that you'd sorta like it to be the case that Cabal is all you need to build any package. As packages and dependencies among packages get more complex (in part, because Cabal facilitates that, which is good) it's natural to make Cabal more complex as well to accommodate more and more needs of package authors. My only point, really, is that you think about these trade-offs whenever adding new capabilities to Cabal. Would it be better to have a standalone tool that Cabal depends on? = Goals of Dependency Chasing = I've been a bit out of the loop on this, so I apologize if I'm re-covering old ground. A simpler goal of a module-chasing system is just to replace the need for other-modules. Other-modules is used in compilation (although ghc --make doesn't really need it) and for haddock and for making source tarballs, and probably for other things. Ideally, the user should be able to specify only "Exposed modules" for libraries and "main modules" for executables, and Cabal should derive the other-modules itself. That's less pain for the user, and you can get around using ghc --make. Well, using ghc --make isn't much of a problem, but other compilers without a --make flag could then be made to work. Maybe this is implemented already? At first this sounds really easy, but then I wonder, how can Cabal know whether a particular module in an import list is a part of a dependency, or actually a part of the package? Can Cabal query ghc-pkg for that kind of information? Can Cabal assume that if it can find the module in the local directory tree that it is a part of the current package? Can you think of another way to make this work? = Overall = Overall, this sounds really cool, and I encourage you all to keep at it! I trust you to decide if adding this kind of complexity to Cabal is worthwhile, and to build a really nice system. I really do think that Haskell should be able to do better than Make here, and it would be a pleasure to feel like we can replace bits of that toolchain :) I'll try to read in more detail and give more feedback. peace, isaac