gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] leapsecond.cache, git


From: Greg Troxel
Subject: Re: [gpsd-dev] leapsecond.cache, git
Date: Thu, 08 Jan 2015 13:52:38 -0500
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.4 (berkeley-unix)

"Eric S. Raymond" <address@hidden> writes:

> leapsecond.cache can be modified during the build but is *not* checked in;
> that's the problem.

The real problem is that a file which is in git is modified during the build.

> The reason there is network access at build time is so the current IERS/USNO
> leapsecond offset will get built into the code ASAP.  Without this hack, 
> someone
> would have to remember to fetch the offset manually, and it would only get
> updated at irregular and probably excessively long intervals.

To me that's catering to people who don't update, but I get it that you
want to do that.

>> But if this is going to happen, then there should be something that
>> either fetches the new file or copies the source file an objdir file if
>> that doesn't work, so that this problem doesn't happen.
>
> I don't understand this prescription, sorry.  

What I meant is:

  have a leapseconds.cache checked in, and keep it up to date.  But call
  it leapseconds.cache.in

  during the build, if the logic wants to fetch, fetch
  leapseconds.cache.
  If not, cp leapseconds.cache.in leapseconds.cache

This gets your goal of up-to-date at build, and avoids modifying a file
From git and giving warnings about unstaged changes, which leads to one
typing:

  git reset --hard -- leapseconds.cache

and being told that hard reset does not work with paths.  I guess I need
to read the docs for reset yet again, because it's too late for reset to
become easy to understand ;-(

Attachment: pgpyjQuuPzPFP.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]