On Wed, Dec 01, 2004 at 09:21:33PM -0800, Isaac Jones wrote:
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.
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.
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).
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.
OK, so this description will be there whatever build system you use. The build information would be only for Simple.
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.
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.