Suggestion re altering the build system

[Manuel M T Chakravarty]

Simon Marlow wrote:
> 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.)
> 
> 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.

Manuel