cabal release

[Isaac Jones]

John Meacham <john at repetae.net> writes:

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

To be fair, this isn't completely Cabal's fault.  Perl, Python, bash,
etc can all put #!/usr/bin/perl or whatever at the top of scripts.
For Haskell we're not there yet and the fact that we have multiple
major compilers is not really a good reason.

I propose that each haskell compiler / interpreter come with
runhaskell.  It should check to see whether runhaskell exists already
and if so, leave it alone.  If not, provide it.  That should probably
be tweakable with the configure script.

Whether Cabal comes w/ the compiler is invoked with runhaskell is a
separate issue.  For simplicity in bootstrapping, I think it should.
Perl and Python also do it this way, as I understand.

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

Simon pointed out one problem with this.  I'm definitely thinking
about relaxing the Setup.hs requirement, but I only want to do this
once we understand the implications.  Those implications will become
more clear once we have things like cabal-install and cabal-get in
active use.  If almost everyone is using cabal-install and
defaultMain, then a two-line tweak to cabal-install will relax the
Setup.hs requirement.

> seperating cabal into its own program would also be a good place to
> provide a unified compiler independent 'runhaskell' script that can have
> logic for finding and running an appropirate compiler so people don't
> have to maintain an appropriate link to runhugs,runghc, or runjhc...

I don't think this really has anything to do w/ Cabal, and I don't see
why they should be bundled.  There's certainly no logic in Cabal right
now that'll make compiler preferences particularly easy to implement.

> while having a source code interface makes a lot of sense for
> single-source implementation-defined languages like perl, I think it is
> very inappropriate for multi-source, compiled programs. Especially when
> it gains you absolutly nothing other than headaches. The chance that
> someone will have such an absurdly odd build setup that one of the
> standard cabal models won't apply AND they can simulate the cabal
> interface exactly are virtually nil and if such a thing does exist, a
> build-style: custom will take care of it. 

As Simon pointed out, build-style: custom is implemented w/ hooks
right now, and there are certainly programs out there using hooks,
though not many of them.  They're not particularly absurd build
systems either.

> You might not even have a haskell compiler on the system you want to
> run cabal on.  (cross-compiling, bootstrapping)

You could always compile the setup script on the cross-compiling
machine.  I do like cabal-install, though, and I think that's the way
of the future.


peace,

  isaac