Hi Ross, I'm definitely happy to add more optional fields to the package description file. I knew that the need for such would come up. But the interface to cabal is the required description file fields and the required Setup arguments. How do you maintain that interface if you're generating the required fields of the description file with the Setup program itself? (I'm assuming that you are having Setup configure call the ./configure script or something?) The idea behind making the cabal description file so easy to parse is that other tools can get information like the package name and version from the cabal description file, rather than the description file sucking it in from someplace else. I believe this is what the Debian package generation tools do, for instance. Where do the PACKAGE_NAME, etc. values come from, BTW? A hope with the cabal was to be able to have a Setup.description file at the top level of something like a tarball. Layered tools like Hackage know where it is and how to parse it. If you don't have it in the source tarball, but rather generate it during build time, that breaks this model. The simple build infrastructure is not meant to build everything, though it would be nice if it could build most things without the help of Make and friends. The key is the interface to cabal which allows for layered tools like Hackage and the Debian package generator to come about. You can always use Haskell itself in the Setup file to find the list of modules or what-have-you and call the functions exposed by the simple build infrastructure. That's why the Setup program is a full-blown Haskell program. peace, isaac