Suggestion re altering the build system

[Simon Marlow]

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