brainstorming ways to stabalize Cabal interface?

[Isaac Jones]

As to Duncan's first mail, I am becomming more inclined to agree on an
official wrapper script (which is why I started the cabal-install
effort).

Duncan Coutts <duncan.coutts at worc.ox.ac.uk> writes:

(snip)
> We've had a few interface changes and inconsistencies before and
> generally in practise:
>       * At one time people were supposed to use ./Setup.lhs and the
>         Setup.lhs file was supposed to invoke runhaskell via the #!
>         method.
>       * Some packages supply Setup.hs rather than Setup.lhs.
>       * Some packages supply no Setup.(l)hs at all.
>       * Some instructions suggest to use runghc Setup.lhs rather than
>         runhaskell Setup.lhs on the basis that one is more reliable.

I can undertand how these have been a problem, and it would be good if
we could enforce consistency or write tools to make consistency less
important.  BTW, these don't represent any interface changes, just
people failing to conform to the standards.  The story has always been
"Provide a Setup.hs or Setup.lhs that the end user compilers or
interprets somehow."

John M. Says:
> yes, yes, a thousand times yes. cabal needs to be a program instead
> of or in addition to a library. probably in addition to since the
> library certainly has a lot of useful functionality.

Some of the reasons that I still have resisted makeing cabal into a
program are that I've been hoping that cabal-get would make that less
necessary, but cabal-get is not yet ready.  I've also been hoping that
runhaskell would become ubiquitous, but it hasn't.

But if I agree to this, you have to get it going for JHC ;)

peace,

  isaac