[U-Boot] [PATCH][RFC] Update U-Boot's build timestamp on every compile

[Peter Tyser]

Hi Wolfgang,

> > __TIME__ and __DATE__ aren't ideal as they are only updated when the
> > file that contains them is recompiled.  For example, during the normal
> > modify/build/test cycle the version string remains the same for an 85xx
> > board as start.S would not be recompiled.  So any number of U-Boot
> > compilations can contain different code, but have the same build
> > time/version string.  eg when a board boots up and spits out:
> 
> Actually the time stamp is completely useless in determining  if  the
> code is the same or different. I can compile the same code many times
> resulting  in  different time stamps and yet it's the very same code.

The code won't be the same - the version string will be different and
the different binaries would have different md5sums.

> 
> > U-Boot 1.3.4 (Aug  7 2008 - 12:32:20)
> ...
> > the code really may not have been compiled on Aug 7th, it could have
> > been compiled today, yesterday, etc.
> 
> Who cares when it was really built? If you are working in the
> recommended environment (i. e. using git) then you can be sure that
> this was the code of the v1.3.4 release; otherwise you would have seen
> something as
> 
> U-Boot 2008.10-rc2-00018-g8fd4166-dirty (Sep 30 2008 - 13:42:17)
> 
> This clearly tells you which version the code was based on (and  that
> it contains local modifications that were not yet checked in).

Which local modifications though?  Until I make another commit every
version string will be the same.

> > It would be nice in my mind if every compile of U-Boot resulted in a new
> > build time string.  Thus you could easily determine which version is
> > programmed on a board during bootup, by looking at a binary on your host
> 
> Timestamps are not suitable to provide this type of  information.  If
> you care about which code you are running, than make sure to use git.

I do, but the minor annoyance of having the exact same version
string/time stamp for different code still exists for uncommited
changes.

> > Also, if a board used __TIME__/__DATE__ in more than one location, it
> > could be confusing as the times wouldn't be identical.  For example, if
> 
> Why would that be confusing? It seems natural to me that time changes
> when  you  do  several  things  sequentially.   If   a   board   used
> __TIME__/__DATE__   in   more  than  one  location,  then  the  board
> maintainer either did this intentionally (and thus wants to  acchieve
> this  result),  or  he  did  it without thinking, in which case it is
> obviously not an important issue to him).

I agree that its not an important issue, but that's not to say it
hasn't/won't confused customers/developers.  eg the first time I noticed
it, it fooled me into thinking my flash wasn't properly programmed after
updating u-boot.

> > the build time were printed in common/lcd.c, it would not be identical
> > to the time printed on the serial port since lcd.c was not compiled at
> > the same time as cpu/mpc8xx/start.S.
> 
> If you care about reliable version information, use the git based ID
> strings.

I use git, but its version strings only change when commits occur.  I
think having an accurate build time stamp would be a nice feature.
FWIW, Linux handles this "issue" very similarly to my proposed solution
so that it can have its pretty banner.  It even takes it a step further
and gives a specific compile number (#15):

Linux version 2.6.23.17 (ptyser at ptyser) (gcc version 4.3.1
(crosstool-NG-xes) ) #15 SMP Wed Aug 6 11:45:55 CDT 2008


I know this patch isn't a big deal, but I think it would be a valuable
change.  If others don't agree I'll drop the issue.

Thanks,
Peter