[SeaBIOS] [PATCH] buildversion.h: use the last git commit as timesource if tree is clean

[Kevin O'Connor]

On Mon, Jun 08, 2015 at 08:58:52PM +0200, Peter Stuge wrote:
> Kevin O'Connor wrote:
> > > > If the new "VERSION=" parameter is not provided then the default build
> > > > version remains unchanged.
> > > 
> > > I prefer Alex' patch, because it defaults to reproducible but
> > > provides more information if the tree has been modified, all
> > > automatically.
> > > 
> > > A user parameter like your VERSION *on top of that* is fine, but why
> > > not have reproducible by default like with Alex' patch when that
> > > doesn't really lose any information?
> > 
> > I find value in the hostname and date on trouble reports - it helps
> > determine if the binary was built by a distribution and it can help
> > backtrack to the gcc/binutils/etc. versions.
> 
> Aha! Maybe we can do one even better then - and include explicit
> information about the gcc/binutils/etc. versions instead of something
> implicit in the hope that it helps backtrack. Having explicit
> toolchain information is valuable also for reproducible builds.
> 
> Build date - sorry, I'm not convinced. This is another heuristic.
> Build date together with toolchain is not a good unique identifier.
> 
> How about (calculating and?) showing a simple checksum of the binary
> at runtime instead?
> 
> My point is that you and reproducible builds actually want the same
> thing, but that your chosen method makes things more difficult for
> reproducible builds, and I think we can find a method that works for
> both.

If someone can submit a patch that provides decent information on the
toolchain then I'm certainly open to using it instead.  The toolchain
is quite varied though (binutils, gcc, make, shell, python, etc.) so
it's not an easy task.

A checksum doesn't help me - it can demonstrate something is different
in the toolchain, but gives no clue on what is different.

> > I find value in the timestamp during debug cycles as a means of
> > verifying I'm running the correct code during a test run.
> 
> Maybe you agree that this is a corner case which could warrant a
> little special effort, e.g. a new make debug.bin target, given the
> benefits of having the default build be reproducible?
> 

Agreed.

> 
> > So, I'm against changing the default to lose this information -
> > either in the debault SeaBIOS build or the default coreboot build.
> 
> But only because the current suggestions mean you lose information,
> right? Not per se?
> 

Yes.

-Kevin