Hi, First of all I want to thank Isaac Jones for his work on Cabal. There are a few issues I would like to raise. 1) Cabal files can have different names, yet only one can exist in a directory. I've been told that the reason for the former is that Isaac wants to support building multiple packages in a directory, but currently the feature isn't implemented, so only one cabal file is allowed. Certainly, it would be a nice feature, but more importantly it seems that it would require some API changes or additions which should be made sooner rather than later. Is there a document describing how it would work? Is there a roadmap, a schedule for implementation? 2) As I have pointed out earlier, some aspects of the 'cabal' installation are specified at configure time, others (whether the package is --user or --global) must be specified at install time. In effect this means that the configuration is spread out over multiple commands, which is rather unsavory. 3) The way that a 'cabal' package with a 'configure' script should be built is not easy to determine. There are some very useful programs (http://toastball.net/toast/) which build and manage packages of all kinds automatically, by running 'configure' with a local prefix, etc. How should these tools be extended to work with 'cabal' packages? With some 'cabal' packages, the user is supposed to run 'configure' first, and then 'runhaskell Setup.hs'. With other 'cabal' packages, the user is supposed to just run 'runhaskell Setup.hs', and this will run 'configure' automatically. Is there a right way? Is there a way to distinguish the two types of packages automatically? 4) Cabal's inability to let users specify package.conf-s other than the user or global package.conf, and ghc's refusal (and that of other compilers) to let users specify paths for things via environment variables, not only complicates the task of tools like 'toast' (above) but makes it hard to create a "test" or otherwise isolated installation of a library or other package. For C libraries all I have to do is add, e.g., $HOME/.toast/armed/include to CPATH and everything works - whereas all of my haskell libraries would have to share the same user package.conf in order for using them to be manageable. To be sure, environment variables are not entirely necessary to do this, the relevant values could be explicitly passed between each stage of a build, but environment variables make the task much simpler. In any case, functional programming is about modularity. We should ask our compilers and packaging tools to support modularity as much as possible as well. To lag behind 'gcc' and 'autoconf' is not acceptable. 5) It seems that there should be a way to build multiple packages which depend on each other, in such a way as that the first package doesn't have to be installed for the second package to be built. In other words, perhaps something like a dummy installation as in #4 is called for. I have seen mention that support for building multiple packages is planned, but how? When? What stage of implementation are we in? 6) I think it should be easy to use 'cabal' for development; however, when I am building a package with multiple executables, every 'build' seems to re-link each executable, regardless of whether it needs re-linking or not, which is quite slow. Maybe this is a bug in ghc, but it would be good to fix it or work around it. In the same vein, it would be nice to have a standard command that invokes "runhaskell Setup.hs" but with fewer keystrokes. I'm not sure how much of this Isaac has planned out on his own and is busy implementing, vs. how much is waiting for someone to write a design document for. I probably don't have time to do much work on implementation, but I could be willing to, say, start a page on the wiki outlining what I think is involved, what the API should look like, etc., if this has not been done yet. Regards, Frederik