Detect out-of-date saved-structures.h

With this change, this package will fail to build if saved-structures.h is not synchronized with structures.h.

Recall that structures.h is generated during compilation in a Linux environment, which is not available when compiling for firmware.  I considered removing saved-structures.h and committing structures.h directly, but if we tested changes by doing an emerge instead of a "local" compilation, the working copy of structures.h would not get updated.  This is a safer way of ensuring they stay in sync.

(This review used to include a version string generation, but the idea was faulty.)

[Luigi Semenzato, 2010-06-23 01:16:39]

With this change, running "strings libtlcl.a | grep GITV" yields the (short)
revision ID of the TLCL source code in our repository.

However, this isn't enough, as we should also commit version.h---and I am going
to send separate mail to discuss this issue.

[Randall Spangler, 2010-06-23 04:56:31]

Interesting.  

This works nicely if the package is built on Linux, but less well if it's pulled
from git.chromium.org as a source tarball (which is what the IBV does).  

Also seems like this will return a different string in a branch vs. head.

Perhaps we could use a pseudo-version which is the md5 of (all .c and .h files)?
 That's constant across SCM systems, and can be checked in without altering the
version (unlike the git rev ID). 

On 2010/06/23 01:16:39, Luigi Semenzato wrote:
> With this change, running "strings libtlcl.a | grep GITV" yields the (short)
> revision ID of the TLCL source code in our repository.
> 
> However, this isn't enough, as we should also commit version.h---and I am
going
> to send separate mail to discuss this issue.

[Luigi Semenzato, 2010-06-23 06:53:51]

I am going to look at this some more.  Some initial thoughts:

On 2010/06/23 04:56:31, Randall Spangler wrote:
> Interesting.  
> 
> This works nicely if the package is built on Linux, but less well if it's
pulled
> from http://git.chromium.org as a source tarball (which is what the IBV does).
 

The IBV is not using this Makefile---they are using Makefile.firmware.

> Also seems like this will return a different string in a branch vs. head.

You are right, this probably won't work because the git version will change with
the commit, and the next time around this won't compile.  Sorry.

> Perhaps we could use a pseudo-version which is the md5 of (all .c and .h
files)?
>  That's constant across SCM systems, and can be checked in without altering
the
> version (unlike the git rev ID). 

Yes, we could---maybe it's the only way to automatically generate a version ID. 
We have to be careful to include all the sources.

> 
> On 2010/06/23 01:16:39, Luigi Semenzato wrote:
> > With this change, running "strings libtlcl.a | grep GITV" yields the (short)
> > revision ID of the TLCL source code in our repository.
> > 
> > However, this isn't enough, as we should also commit version.h---and I am
> going
> > to send separate mail to discuss this issue.

[Luigi Semenzato, 2010-06-23 15:44:27]

On 2010/06/23 06:53:51, Luigi Semenzato wrote:

I reduced the scope of this change and changed the reviewer from Randall to
Gaurav.

[gauravsh, 2010-06-23 17:21:52]

Has this already been pushed? The issue seems to show up as closed on
the codereview site.

On Wed, Jun 23, 2010 at 8:44 AM,  <semenzato@chromium.org> wrote:
> On 2010/06/23 06:53:51, Luigi Semenzato wrote:
>
> I reduced the scope of this change and changed the reviewer from Randall to
> Gaurav.
>
> http://codereview.chromium.org/2864018/show
>



-- 
-g

[gauravsh, 2010-06-23 18:17:39]

lgtm