Version Strings - doesn't show recent edits

Hal Murray hmurray at megapathdsl.net
Mon Apr 17 01:52:07 UTC 2017


gem at rellim.com said:
> Before we get into how much extra work this adds to the build, what exactly
> is the extra info we would want? 

I'm not sure we need any "extra" info.

The NMEA driver wants as late a time-stamp as it can get.  It will work with 
the last commit date.  It will work better with the actual build date - 
more-better as the time between commit and build increases.

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

I view that as an implementation detail.  I assume the answer is yes.

Currently, the version string comes from autorevision and the time-stamp that 
NMEA uses comes from __DATE__ or MKREPRO_DATE and friends.

We could fix the NMEA problem by using the time-stamp from autorevision.  
There is a scanf that pulls fields from __DATE__ and __TIME__.  It should be 
a simple change to use the string from autorevision in that step.

We could remove a lot of cruft from libntp/ntp_calendar.c if whatever 
time-stamp was used for NMEA was pre-processed by an external script rather 
than at run time.

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

I'd be happy with the build time.  (as compared to the current last commit)

If you want to do something fancy like the latest edit of any sources that 
would be OK too, but don't forget to include config.h



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

The problem with schemes like that is not which file to use, it's how to 
recover if the time on that file ever gets set into the future.

We could use something like the leap-seconds file which gets updated 
occasionally as long as the update mechanism preserves the last-edit date.




-- 
These are my opinions.  I hate spam.





More information about the devel mailing list