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

Peter Tyser
2008-10-21T14:40:29Z

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