Simon Marlow:
Manuel M T Chakravarty wrote:
I think all *core* libraries must switch. Seriously, requiring GHC
developer to use a mix of two vcs during development is a Very Bad
Idea. Don was excited about getting more people to look at the
source when it is in git (see the comments he posted from reddit).
By requiring two vcs you will get *less* people to look at the
source.
This is not only to get the sources to hack them, but you
effectively require developers to learn the commands for two vcs
(when they are already reluctant to learn one). For example, often
enough somebody who changes something in GHC will modify the base
package, too. Then, to commit the overall work, you need to commit
using both vcs. If you need to branch for your work, you need to
create branches in two vcs (no idea whether the semantics of a
branch in git and darcs is anywhere similar). When you merge your
branch, you need to merge in both vcs. You can't seriously propose
such a set up!
I completely agree this is a problem. The main obstacle with just
switching the core libraries is that they are shared by other
implementations and other maintainers. So I see no alternative but
to create forks of those repositories for use by GHC, unless/until
the other projects/maintainers want to migrate to git. Some of the
repositories are not shared - for example ghc-prim, integer-gmp,
template-haskell, and these don't need to be forked.
One way we could create the forks would be to create a git repo for
each package with two branches: the master branch that GHC builds,
and a separate branch that tracks the main darcs repository, and is
synced automatically whenever patches are pushed to the main darcs
repo. We'd have to explicitly merge the tracking branch into the
master branch from time to time. When we want to make changes
locally, we can just commit them to the GHC branch and push the
changes upstream in a batch later (and then we'd end up having to
merge them back in to the GHC branch... but hopefully git's merge is
clever enough to avoid manual intervention here). This is
complicated and ugly of course; better suggestions welcome.
Yes, it's a pain. However, it is better than two vcs for one project.
I *strongly* object to moving to git before this isn't sorted out.
As Roman said before, GHC is heading into a dangerous direction.
It gets progressively harder to contribute to the project at the
moment. First, changing the build system to Cabal. Now, proposing
to use two vcs. Somebody who is new to the project not only has to
learn the internals of GHC, but they also have to learn two new
vcs, and if they need to change the build system, they need to
learn a new build tool. Raising the bar for developers to
contribute to a project has been proven to be a very bad idea many
times. Let's not take GHC down that path.
I'm not completely convinced we need to have this all worked out
before GHC switches, although it would be nice of course. We
currently have infastructure in place for the build to work with a
mixture of darcs and git repositories, and existing developers
already have to learn git anyway. They just need to remember to use
darcs for libraries and git for the main GHC repo, and this is only
a temporary situation.
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?
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.
Manuel
PS: Just for some more collateral damage. Did anybody check whether
the Mac OS installer support and the -unfortunately, only partially
working- support to compile for older OS X versions that I added to
the *makefiles* still works with the Cabal-based system? I doubt it.
Took me quite a while to get all this going, and I am not very well
motivated to spend a lot of time to figure out how it might work with
Cabal. IMHO using Cabal for anything but the libraries was a step
back for no good reason.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
