Manuel M T Chakravarty wrote:
Iavor Diatchki wrote:
The mirroring idea seems complex and fragile. Is there a reason why
GHC has to depend on the repository versions of the "external" (i.e.,
the ones marked with 'darcs') packages? It seems to me that it should
be possible (and desirable!) to make GHC depend on particular released
versions of those packages, and so the source could be obtained in the
same way that it is for other Haskell programs (e.g., hackage). Then,
the revision control system used to maintain those packages would not
be important from the point of view of GHC.
That is basically what I meant to say, too. Only Iavor says it more
clearly!
Which is basically suggesting that there should be no (b) packages, only
(c) (using the classification from Simon's email below).
I think that is probably ok, and desirable as it reduces the number of
different scenarios that the GHC developer has to think about. For the (c)
packages where the GHC git repo contains a snapshot of the package, I can
imagine also checking out the darcs repo into the GHC tree in order to work
on the library, and as long as git ignores the _darcs directory everything
should work fine. We can push changes to darcs, and also commit the new
snapshot with git in the same tree.
Of course, we don't plan to do this often, because we'll be using released
versions of these packages. But I can imagine it being useful sometimes:
for example, we'll need to work on Cabal a bit for the new build system,
but after that I hope we'll be more decoupled from it.
Cheers,
Simon
Manuel
On Mon, Sep 15, 2008 at 5:58 PM, Manuel M T Chakravarty
<[EMAIL PROTECTED]> wrote:
Simon Peyton-Jones wrote:
In what follows the "Boot Libraries" are the ones required to build
GHC.
* So we propose the following:
- The GHC repo will be in Git
- Each Boot Library will
(a) either be mastered in Git, with a read-only Darcs mirror
(b) or be mastered in Darcs, with a read-only Git mirror
(c) or be mastered in Darcs, with an occasional, manual
process to copy a snapshot of the library from Darcs
into GHC's Git repo. (Those Git files should be
considered read-only.)
For (b), will the Git-mirror be automatically updated or patches from
darcs
be pulled manually?
- That means that if we want to modify a Darcs-mastered library
we'll have to get the Darcs version, make the patch, test it,
push it, and then the Git mirror will be right. Inconvenient,
but we can live with that. We might even arrange it to be possible
for super-developers to use the Darcs repo (rather than the mirror)
direct from their tree. Ordinary developers can continue to be
Git-only.
[..]
* Our specific proposals for the master VCS for each boot library are:
hsc2hs darcs
haddock2 either: up to David Waern
packages/array git
packages/base git
packages/base3-compat git
packages/bytestring darcs
packages/Cabal darcs
packages/containers darcs
packages/directory darcs
packages/editline darcs
packages/filepath darcs
packages/ghc-prim git
packages/haskell98 darcs
packages/hpc either: up to Andy Gill
packages/integer-gmp git
packages/old-locale darcs
packages/old-time darcs
packages/packedstring darcs
packages/pretty darcs
packages/process git
packages/random darcs
packages/syb either: up to Utrecht
packages/template-haskell git
packages/unix git
packages/Win32 git
You do not distinguish between (b) and (c) in that list. Personally, I
think, every (b) library is a Bad Thing if the Git-mirror update is
*automatic*. Why? The setup discourages the library developer from
validating their library changes against the GHC build.
In other words, every single library that is marked as "darcs" above
should
be used by ghc at arms length. That is, ghc should not use the bleeding
edge development version, but the latest stable version (or something
similar). When there is a new stable version, the person maintaining
the
GHC Git mirror of the library ought to validate GHC with the new library
version and only then update the mirror (or the in-place copy in
GHC's Git
repo). If it is not possible to use a library's latest stable
version, the
library is too tightly coupled with GHC to live in a darcs repo.
Manuel
_______________________________________________
Libraries mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
