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