Suggestion re altering the build system

[Stefan O'Rear]

On Fri, Jun 01, 2007 at 05:09:23PM +0100, Simon Peyton-Jones wrote:
> |   1. We tag all the repos after a successful bootstrap on each platform.
> |      Main problem with this: profusion of tags, obscuring 'darcs changes'
> |      and 'darcs query tags'.  Space itself isn't really an issue; a tag
> |      only adds a few hundred bytes.
> |
> |      We could mitigate the effect by rate-limiting the tags, say only tag if
> |      there hasn't been a tag in the last week.  Then we'd get one
> |      guaranteed-buildable state per week or so, which seems reasonable.
> |
> |   2. We keep a separate set of repos that are only updated after a successful
> |      build.  Perhaps one set of repos per platform.
> |      Main problem with this: ensuring atomicity during the update (probably
> |      not likely to be a significant problem in practice).
> |      Second problem: this doesn't store the repo state of every successful
> |      build, only the most recent one.
> |
> | Personally I lean towards (2), as it's much easier to implement.  Any further
> | comments?
> 
> (2) seems good to me.  Furthermore, if we published
>         Last good build is at repo http://darcs.haskell.org/ghc-2007-02-09
> (so the date is in the repo name), and refrain from publishing until the repo is really there, there'd be no atomicity issues would there?
> 
> (We can just delete older ones after a bit.)

3 (mentioned earlier): Like 1, but don't push the tags.  Instead we
darcs send -o them and publish.  The workflow for a checkout is:

darcs get /my/local/fullghc/repo /ghc/build/path
cd /ghc/build/path
wget http://url/of/latest-tag
darcs apply latest-tag
darcs unpull --from-tag=BUILDS

This has the space/network usage of (1) and the infrastructure ease of
(2).

Stefan