GHC repos etc
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Thu Oct 22 19:58:51 EDT 2009
Simon Peyton-Jones:
> As Simon says below, we've decided to back out the new wget
> mechanism for tarballs.
I am very glad to hear this.
> a) Make a new darcs repo solely for the Windows Mingw blob.
> b) This is gotten by darcs-all in the same way as any other library
> c) Obliterate the Mingw-blob patches from the GHC repo
>
> Concerning (b) you may wonder whether you need to get this blob if
> you are on Unix. Well no. But 'darcs-all get' already gets the
> unnecessary Win32 libs on Unix, and the unnecessary Unix libs on
> Windows. We could fix that, by making darcs-all a bit more
> selective, and Ian will think about that. (When building source
> *distributions* we want both, because we have just one source
> distribution for every platform.)
To be honest, I don't mind if it gets the windows-related repos on
unix. Sure, it'll make darcs-all pull a bit slower (but it is so slow
from AU anyway, that I always go and do something else in the
meantime, so it doesn't matter to me) and it'll take a bit of disk
space, but disk space is sooooo cheap these days that I don't think we
need to burn cycles on saving a little.
IMHO the overriding design criterion for all these repository-related
matters is simplicity. The simpler the setup, the less likely it is
to break.
> | Also, since we now have at least 12% of our repo taken up by two
> huge
> | binary patches, I suggest we take the unprecedented step of
> obliterating
> | those patches from the master repo. Unfortunately we also have to
> | obliterate 8 dependencies. We could have darcs-all check for the
> | presence of the obliterated patches and suggest unpulling them.
>
> Ian will make darcs-all do this check; and will emit very clear
> guidance about the 'unpull' commands you have to execute. So the
> effect should be:
> - Doing the unpull is easy
> - If you forget, you'll get a reminder
> And as a result the GHC repo will be noticeably smaller.
As I already said, I am not worried about disk space (especially space
taken by clean repo, given how much bigger a repo gets when building).
I assume that the patches that you want to obliterate are *after* the
last tag/checkpoint. Otherwise, I can't see how this plan is going to
work.
And thanks for quickly sorting out the issue with wget!
Manuel
More information about the Cvs-ghc
mailing list