Version Strings - doesn't show recent edits

[Gary E. Miller]

Yo Hal!

I see a strong synergy between this and bug #268.  Hal wants builds
that are identifiably touched by developer actions.  Repro builds
want the exact opposite, builds that validate zero developer changes.

Flip sides of the same coin?

On Sun, 16 Apr 2017 12:18:18 -0700
Hal Murray <hmurray at megapathdsl.net> wrote:

> > 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.

Before we get into how much extra work this adds to the build, what exactly
is the extra info we would want?

For repro builds we replace __DATE__ and __TIME__ with MKREPRO_TIME
and MKREPRO_DATE.

Could MKREPRO_xxx be derived easily from last the lsat commit meta data?

> I'm willing to rebuild a few extra modules in order to get useful
> version strings.

What would you define as 'useful' for a dev build?

> > 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.
> We already got rid of that usage as part of the time_t 32 vs 64
> discussion.

+1.

> 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.

Gentoo on RasPi sets the time with a special file that is updated
now and again.  ntpd could use the file time on the driftfile.  Or
many other possibilities.

If we just assume last git time is valid then that gives us a 60+
year window where we know the pivot.

> > The indispensable one is the use in the NMEA driver.

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

+1, or just use MKREPRO_xxx

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

Yes.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170416/33f7bea3/attachment.bin>