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: Eric S. Raymond
Subject: Re: [gpsd-dev] leapsecond.cache, git
Date: Thu, 8 Jan 2015 21:07:30 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Greg Troxel <address@hidden>:
> "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.

Right.  I don't think there is any way to do this right that doesn't have
this problem.

> 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 ;-(

OK, but under your method, how does the leapsecond update get into the 
codebase we ship?

Remember, we ship tarballs too.  One of the goals of the update method
is to make sure that whenever anyone makes a tarball from a repo
checkout the current BUILD_LEAPSECONDS value is up to date in
timebase.h.

That means that something that changes on each IERS leap-second change has to 
get
*committed*, not just copied.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

Attachment: signature.asc
Description: Digital signature


reply via email to

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