building haddock?

[Simon Marlow]

On 01 February 2006 17:45, Isaac Jones wrote:

> "Simon Marlow" <simonmar at microsoft.com> writes:
> 
>> On 31 January 2006 21:38, Isaac Jones wrote:
> (snip)
>>> Ahem. Cabal-install.
>>> 
>>> It doesn't read that field yet, though.
>> 
>> Do you intend cabal-install to be the main interface to Cabal? 
>> That's what Duncan was proposing (and others have suggested) - that
>> we deprecate the use of 'runhaskell Setup.lhs' as the interface to
>> Cabal in favour of a program to do the same.
> 
> I don't know if cabal-install should be the main interface or not; I
> think it's worth experimenting with.  As far as I know, I'm the only
> one who's tried it :)
> 
>> Certainly there doesn't seem much point in having *both*
>> cabal-install and another wrapper, so clearly they should be the
>> same thing.  I do think this is the way to go, though.
> 
> You think we should move away from saying that "setup" is the
> interface?  Would we start distributing cabal-install w/ the
> compilers, or expect users to install it on their own?

I'm referring to discussion from a couple of weeks ago:

  http://www.haskell.org//pipermail/libraries/2006-January/004815.html

basically, yes, I think Cabal should come with a tool that you run
instead of 'runhaskell Setup.hs'.

This will actually result in more consistency, because as Duncan pointed
out in that thread, there are currently lots of ways to run Setup.hs.

The tool can check for the cabal-version field before it does anything,
and run the Setup script with the appropriate version of Cabal (or fail
if it can't find it).  This neatly fixes the problem of changing APIs in
Cabal.

The command line interface for the tool can be exactly the same as Setup
right now.  Plus another option to behave like cabal-install, maybe.

> The problems with the setup script are mainly:
>  1) the interface changes (though that is hopefully a short-term
>  problem) 2) we can't count on runhaskell being installed
> 
> A better solution might be to work hard on stabalizing the interface.
> I would like to try to stabalize cabal and move future development
> into layered tools.

Stabilizing the API and layered tools are both good, but I'm sure we'll
want to extend the API in the future.  Using a small wrapper program
instead of invoking Setup.hs directly ensures we'll be able to do this
smoothly in the future, without breaking lots of Setup scripts.

I don't think this is that big a deal, it isn't a fundamental design
switch, the functionality is still implemented in Haskell and completely
customisable by each package, all we're doing is replacing the words
'runhaskell Setup.hs' with 'cabal-setup' (or something).

Cheers,
	Simon