patch applied (ghc): Detect the snapshot version number using
darcs
Simon Marlow
simonmarhaskell at gmail.com
Wed Feb 7 04:28:29 EST 2007
Ian Lynagh wrote:
> On Tue, Feb 06, 2007 at 01:26:52PM -0800, Simon Marlow wrote:
>> Tue Feb 6 13:25:36 PST 2007 Simon Marlow <simonmar at microsoft.com>
>> * Detect the snapshot version number using darcs
>> For non-release builds, we want to append a date to the version number
>> (e.g. 6.7.20070206). Previously this was done by the nightly build
>> script, this new method figures out the snapshot version by querying
>> the darcs repository and finding the date of the most recent patch
>> (actually it finds the most recent of the last 100 patches, but that
>> should be good enough). This is done by the configure script.
>>
>> To handle source distributions, we create a file VERSION in the
>> top-level directory that contains the version number, and ship this in
>> the source distribution. The configure script picks up the version
>> from this file if it doesn't see a _darcs directory.
>
> Would it not be nicer for the buildbot scripts to put the date (and
> perhaps even time) of the start of the build somewhere? The darcs hack
> is still nice for manual builds, though; perhaps always use VERSION if
> it exists (release tarballs and buildbot builds) and ask darcs
> otherwise?
You're right that this hack isn't perfect, mainly because it has a one-day
granularity: we can't tell the difference between a 6.7.20070206 with sources
obtained at 0:00 and one at 23:59. Should we reduce it to one-minute
granularity, e.g. 6.7.200702062359, do you think? Or did you have something
else in mind?
I like this scheme a lot more than the previous one. Now regular users who pull
and build GHC will get a snapshot version, and if you pull and re-configure in a
build tree the version will be updated automatically.
If you have local patches, or are missing some patches relative to the main
repository, then the version you get will not be as meaningful. This is a
problem, but I don't expect it will have much impact.
Cheers,
Simon
More information about the Cvs-ghc
mailing list