Version Strings - doesn't show recent edits

[Hal Murray]

> It would be possible, with some hackery, to bump the version string on every
> edit.  However, this would mean that every single build would always
> recompile every file that included the generated version symbol.  This would
> be irritating, especially given the existence of slow buildbots; qemu images
> for exotic architectures would be right out. 

My proposal was for a option that defaulted to off.  Buildbots wouldn't 
enable it.

I'm willing to rebuild a few extra modules in order to get useful version 
strings.  The when-to-update complexity doesn't have to be part of waf (but 
that would be great).  I have a script that does the rebuilding.  It could do 
whatever is appropriate.  It already deletes ntpd/version.h, leftover from 
before we switched to autorevision.

We already have to do the relink step.  If recompiling ntpd is too slow, we 
could move the version string out to a separate module.


> The maybe-dispensible one is the use of build-time pivoting to find the
> nearest time corresponding to an l_fp across ntp-date calendar cycles. If we
> toss that we lose the ability for ntpd binaries built in different eras (but
> within a half-cycle of each other) to settle on a common timebase and
> interoperate. 

We already got rid of that usage as part of the time_t 32 vs 64 discussion.  
We now depend on the system time being "close enough".  The interface across 
the 32-64 boundary is a delta-time rather than the correct time.

I think that puts the pivot time at 1970.  We could advance that by 40+ years 
by adding some code that would update the system time to the release date if 
it was before that.

We could get a "better" time from the file system.  That would be a disaster 
if the time ever got into the future long enough to write whatever part of 
the file system we get the time from.


> The indispensable one is the use in the NMEA driver. In theory we could bow
> to the distros' desire for reproducible builds, throw that code out, and
> pass the buck to GPSD.  I don't want to do that because, as they say in
> politics, the optics would be bad. 

We could switch that usage to a time stamp that gets updated as part of the 
release process.

The NMEA usage has a lifetime of 20 years after the reference time.  The l_fp 
pivoting breaks after 60+ years.

Is 60 years after the release date good enough for the l_fp pivoting?

Is the difference between 20 years from the release date vs 20 years from 
build time significant?


-- 
These are my opinions.  I hate spam.