Cabal package description sytax

[ross at soi.city.ac.uk]

On Tue, Dec 07, 2004 at 09:50:58AM -0800, Isaac Jones wrote:
> 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.

Another possibility is to have Exposed-Modules in the package description,
and a field in the build info listing modules from that list to be
excluded from a build on this system.

> 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

How about using optional files as the hooks, something like

configure pkg_descr ... =
        configureExists <- fileExists "configure.lhs"
        when configureExists $ rawSystem "runhaskell" ["configure.lhs"]
        buildInfoExists <- fileExists "yourgenerateddescription"
        buildInfo <- if buildInfoExists
                then readBuildInfo "yourgenerateddescription"
                else return (defaultBuildInfo pkg_descr)
        ...

(You'd probably also want some way for configure.lhs to indicate failure.)
I'd also like Setup.lhs itself to be optional, defaulting to the simple one,
which can be precompiled.

> 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?

There can be different tests before and after installation, too,
and the test would need some way of indicating success or failure.
I imagine you have a plan to have Hackage plug into an autobuilder
so the package list can show what versions of what compilers a
package works with -- that would be very useful, not least in flagging
abandoned packages.

> 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.

I'd be keener to have specified file formats with corresponding parsers in
the library.  Lengthy Setup.lhs scripts will be a maintainance headache,
I think.