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