Manuel M T Chakravarty wrote:
Simon Marlow wrote,
Simon Peyton-Jones wrote:
| I understand that incremental builds are more tricky, but during
| teaching session I often have only 2 hours to hack on a day.
I'm still hopeful that a "last-good-build" date or
signature-of-some-kind should do the job. Ideally it goes like this
* Look at GHC dev wiki, get last-good-build signature
* darcs pull -a -upto sig
* make
I'm thinking that "sig" could be a date-and-time, which you
copy/paste from the wiki into the darcs command.
Or am I being naive?
date/time doesn't work well with darcs. Consider the case where we
have a successful build on date T, and then someone sent us a patch P
that they recorded before T. We push the patch, and now "all the
patches up to date T" includes P, but it didn't when we did the
build. This is why we need full tags or contexts to identify the
contents of the tree.
Yes, it has to be tags. And it need to be tags that are in the ghc repo
*and* all core packages. (As those not being in sync is a common problem.)
Not to let this dangle unsolved, let's review the options, with a few further
thoughts:
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?
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
