Cabal package description sytax

[Isaac Jones]

Ross Paterson <ross at soi.city.ac.uk> writes:

(snip)
> 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.

OK.

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

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.

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

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

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?

In addition to the defaultMain functions we have, we would provide:

defaultMainNoReadFuns :: UserFunctions -> PackageDescription -> IO ()
defaultMainFuns       :: UserFunctions -> IO ()

Where:
data UserFunctions
    {
     runTests :: Maybe (IO ()), -- ^Used for './setup test'
     postInst :: Maybe (IO ())  -- ^guaranteed to be run on target
     preInst  :: Maybe (IO ())  -- ^not guaranteed to be run on target
     ...
    }

And a typical main might look like:

main = do defaultMainFuns (emptyUserFuns{preConfigure=myAutoConfFun})

Hmm. This doesn't quite do what you want it to if preConfigure returns
()... Maybe it could return a (Maybe PackageDescription).

Any thoughts here on how to make useful hooks?

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.


peace,

  isaac