gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] scons quirks


From: Eric S. Raymond
Subject: Re: [gpsd-dev] scons quirks
Date: Fri, 15 Nov 2013 16:57:03 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Hal Murray <address@hidden>:
> I think I've tracked down one piece of the puzzle.  revision.h is the key.
> 
> On the rsync-ed to machines, the .git directory gets dropped.
> revision.h contains things like:
>   #define REVISION "2013-11-15T10:25:15.11"
> while on the git-clone-d systems it looks like:
>   #define REVISION "release-3.9-807-g4f440cd"
> 
> On the non-git world, revision.h gets updated each time you run scons.
> In the git world, revision.h doesn't get updated by a second scons.

Actually, it does.  But because scons checks out-of-dateness by MD5 
hash of content rather than timestamp, the update doesn't trigger
any rebuilds.

There is a can of worms here, all proceeding from what we think the
version stamp is for.  There are a couple of other possibilities for
how to update revision.h when there's no .git directory.

1. Never. Your problem goes away, but the version number no longer 
signals that the code has been altered from the repo copy.

2. Only once. In theory, it would be possible for a gitless build to
append a modified suffix (a '+<number>' or something) to the version
string to track the number of modifications. The build system would
have to do its own content hashing. Doable, but fragile enough to
make me twitch a little.

I'm not sure what the right thing is here.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

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