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