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 ([EMAIL PROTECTED]) (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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot