Suggestion re altering the build system
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Tue Jun 5 21:25:07 EDT 2007
Simon Marlow wrote:
> Simon Peyton-Jones wrote:
>> | 1. We tag all the repos after a successful bootstrap on each
>> | Main problem with this: profusion of tags, obscuring 'darcs
>> | 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
>> | build. Perhaps one set of repos per platform.
>> | Main problem with this: ensuring atomicity during the update
>> | not likely to be a significant problem in practice).
>> | Second problem: this doesn't store the repo state of every
>> | 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
>> (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.)
> Indeed, that's a good idea, although it's more work than just pushing.
> We wouldn't want to create a complete new set of repos for every
> successful build, I don't think.
Similar rate limiting as you proposed for (1) could be applied; ie, no
more than one such repo per week.
I don't quite understand why (2) is much easier to implement and having
a tag a week in the main tree marking a buildable state seems quite
attractive to me. Anyway, Option (2) is fine, too.
However, just http://darcs.haskell.org/ghc-2007-02-09 isn't good enough.
We need a consistent set of ghc repo and core packages. At least, in
my experience, it's not uncommon having build problems due to ghc/ and
libraries/base/ being out of sync, and at least when the build system
changes, many build problems are in conjunction with packages.
More information about the Cvs-ghc