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@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