cabal release (was: cabal experiences)

[Simon Marlow]

On 13 December 2005 02:33, John Meacham wrote:

> On Mon, Dec 12, 2005 at 03:14:09PM +0000, Duncan Coutts wrote:
>> On Mon, 2005-12-12 at 14:46 +0000, Simon Peyton-Jones wrote:
>>> If the reason you want 6.6 is to get a new Cabal, why not download a
>>> new Cabal package?  Or is there another reason you want 6.6?
>> 
>> That is exactly the problem. All non-trivial packages need a later
>> version of Cabal since there are many many minor bug fixes and little
>> feature additions in later versions of Cabal.
> 
> This is a large part of the reason I'd like to see cabal as a
> completly separate package from any compiler with a programatic
> interface rather than a library one. things will get very complicated
> when there are multiple major compilers and you have to tell users
> things like 'run runhaskell Setup.lhs, unless your runhaskell points
> to jhc, in which case do runghc Setup.lhs, oh, create a link from
> runhaskell to your proper compiler'.
> 
> We can do so without losing any flexability at all. just add a new
> line to the cabal file
> 
> build-style: (makelike|simple|custom)
> 
> where makelike and simple just call the current cabal library routines
> and custom lets you specify a command that should be run and arguments
> passsed to it. (which can be something like 'runhaskell Setup.lhs')

One usage of Setup.lhs that is becoming more common is to extend the
simple build system in small ways using hooks.  How do you envisage that
working with your scheme?  It looks like we would need to use "custom",
but we're back to needing a to provide the build system as a library,
otherwise every package needs to supply its own complete build system.
I don't immediately see how this solves the problem, but perhaps I'm
missing something.

I'm not against eliminating Setup.lhs in the (common) case when it is
just boilerplate.  But we need to retain the ability to customise the
simple build system, because it's both powerful and necessary.

Cheers,
	Simon