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
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
