Manuel M T Chakravarty wrote:
As far as I am concerned, building GHC is turning into a big mess. We discussed ways to improve it again, BUT I'd rather not see it getting any messier before it gets better. Hence, please let's have a complete plan that we are convinced will work before making any more changes.
As for Cabal - we had a thread on cvs-ghc last week, and as I said there we'd love to hear suggestions for how to improve things, including wild and crazy ideas for throwing it all away and starting again. However, as I explained, there are good reasons for the way things are done now, the main one being that the build system for packages is not written twice.
Yes, we need cabal for packages because we don't want two build systems. However, this does not justify the use of Cabal outside of libraries/. Nobody explained to me why that was necessary. Why change all the rest of the build system. What is the benefit for the ghc project?
GHC is a package, just like any other. The GHC package was the main reason we still had a lot of the old infrastructure for building packages still in the build system, so there was a compelling reason to switch the compiler itself to Cabal, at least. It's true that this change wasn't all win. We gained in some places and lost in others - the build system is more unfriendly to developers now, as opposed to people just building GHC, and that really is something we need to address.
To be honest, if you ask me, I'd go back to the old makefile based system and remove Cabal from everywhere except building of the library packages.
I wouldn't object to dropping the use of Cabal for other tools in the build tree; the reasons for using it elsewhere are certainly not as compelling as for packages. Ian, I realise this means backing out a lot of the work you've been doing recently, and it would mean that we'd lose a lot of time in the runup to 6.10.1, but perhaps it's a step that we need to take to get us back on the right track again? Cheers, Simon