On 02 December 2004 05:22, Isaac Jones wrote:

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.

It seems that we want a format the for the Setup.description file that can both (a) be parseable without any preprocessing to extract a well-defined subset of the full contents (eg. package name, version, maintainer, description etc.) (b) be combined with information collected by './Setup.lhs configure' to form a complete PackageDescription. could we just make up a syntax for splicing in information from the configure step into Setup.description?

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.

Don't forget it can be called Foo.hsproj too, for Visual Studio. This is working now BTW: we can open up a Cabal package in VS and build it. Cheers, Simon