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
