Ross Paterson
I suppose what I'd like is a separation of the build information from the basic package description, with the possibility of the configure step producing the build info to be used by the simple build infrastructure. Having hardwired build info is very limiting.
OK.
Where do the PACKAGE_NAME, etc. values come from, BTW?
They're set by AC_INIT in configure.ac. That was Sven's concern, but you make a strong case for it originating from the package description. (Nothing to stop configure getting it from there, I imagine.)
I'm more concerned about the build information: C compiler options, libraries, include files, frameworks, etc. And the hidden module list, possibly the exposed ones too (though maybe you want that available to your tools).
My hope is to eventually just have the exposed modules list on there (and available to layered tools) and have it determine the dependencies. Same with the main modules for executables. It would be nice if the exposed modules list were available to the tools, but that's not a requirement.
I'm not terribly interested in make-based builds, because they're unlikely to be portable across implementations. So I'd like the simple build to be as useful as possible, and it could cover the vast majority of cases if it had a hook at the configure stage to generate the build info. (Not necessarily cpp, if that makes you ill; Einar's suggestion of using make for this purpose could also work, and there are other possibilities.)
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.
Writing a Setup program is also unattractive, both because of portability worries and the need to keep it up-to-date in the future.
What I mean is that you can have two files, Setup.description, and yourgenerateddescription.in. The former has the required fields and the later has the build information, then main would be something like this: main = do e <- doesFileExist "yourgenerateddescription" when (not e) (system "autoconf yourgenerateddescription.in") desc <- readPackageDescription "yourgenerateddescription" defaultMainNoRead desc So the only issue here is that you have a bit of a configure step no matter what commands they use. It would indeed be nice to have hooks for the commands. I'm a bit worried about making the Distribution.Simple interface complex, but I wanted to add hooks for "test" and "postinst" anyway. The problem is, do we need all of: {pre,post}{configure,build,install}, test? In addition to the defaultMain functions we have, we would provide: defaultMainNoReadFuns :: UserFunctions -> PackageDescription -> IO () defaultMainFuns :: UserFunctions -> IO () Where: data UserFunctions { runTests :: Maybe (IO ()), -- ^Used for './setup test' postInst :: Maybe (IO ()) -- ^guaranteed to be run on target preInst :: Maybe (IO ()) -- ^not guaranteed to be run on target ... } And a typical main might look like: main = do defaultMainFuns (emptyUserFuns{preConfigure=myAutoConfFun}) Hmm. This doesn't quite do what you want it to if preConfigure returns ()... Maybe it could return a (Maybe PackageDescription). Any thoughts here on how to make useful hooks? BTW, I was toying with the idea of using the config file parser from John Goerzen's MissingH in the Cabal, and provide it for Setup.lhs authors to write and parser their own configuration-related files. peace, isaac