Update U-Boot's build timestamp on every compile
RFC PATCH 1/1 Update U-Boot's build timestamp on every compile
Use the GNU 'date' command to auto-generate a new U-Boot timestamp on every compile.
---
I noticed that the build time of U-Boot was not updated on every compile which occassionally threw me for a loop as to whether a new U-Boot binary was programmed, etc. This patch updates a U_BOOT_DATE define on every compile which can then be used in place of the multiple "__DATE__ - __TIME__" preprocessor macros that are currently used.
This also ensures the timestamp will be the same for a board if it uses __TIME__ in multiple files.
Let me know if this would be accepted into mainline and I'll generate a formal patch updating all __DATE__/__TIME__ references.
Makefile | 2 ++ cpu/mpc85xx/start.S | 2 +- 2 files changed, 3 insertions(+), 1 deletions(-)
Makefile +2 -0
@@ -366,6 +366,8 @@ $(VERSION_FILE): @( printf '#define U_BOOT_VERSION "U-Boot %s%s"\n' "$(U_BOOT_VERSION)" \ '$(shell $(CONFIG_SHELL) $(TOPDIR)/tools/setlocalversion $(TOPDIR))' \ ) > [email protected] + @( printf '#define U_BOOT_DATE "%s"\n' '$(shell date +"%b %d %C%y - %T")' \ + ) >> [email protected] @cmp -s $@ [email protected] && rm -f [email protected] || mv -f [email protected] $@ gdbtools:
cpu/mpc85xx/start.S +1 -1
@@ -272,7 +272,7 @@ _start: .globl version_string version_string: .ascii U_BOOT_VERSION - .ascii " (", __DATE__, " - ", __TIME__, ")" + .ascii " (", U_BOOT_DATE, ")" .ascii CONFIG_IDENT_STRING, "\0" .align 4
Signature · 1 line
1.6.0.2.GIT
RFC PATCH 1/1 Update U-Boot's build timestamp on every compile
Quoted 12 lines · Peter Tyser
Use the GNU 'date' command to auto-generate a new U-Boot timestamp on every compile.
Signed-off-by Peter Tyser <[email protected]>---
I noticed that the build time of U-Boot was not updated on every compile which occassionally threw me for a loop as to whether a new U-Boot binary was programmed, etc. This patch updates aU_BOOT_DATEdefine on every compile which can then be used in place of the multiple "__DATE__-__TIME__" preprocessor macros that are currently used.
Quoted 6 lines
This also ensures the timestamp will be the same for a board if it uses
__TIME__in multiple files.Let me know if this would be accepted into mainline and I'll generate a formal patch updating all __DATE__/__TIME__ references.
Instead of U_BOOT_DATE, we could use U_BOOT_DATE (month, day, year) and U_BOOT_TIME (24 hour time) to provide more granularity if others want that level of control.
Peter
RFC PATCH 1/1 Update U-Boot's build timestamp on every compile
In reply to Peter TyserQuoted 11 lines · On Fri, 17 Oct 2008 17:51:21 -0500 Peter Tyser <[email protected]> wrote:
Use the GNU 'date' command to auto-generate a new U-Boot timestamp on every compile.
Signed-off-by Peter Tyser <[email protected]>---
I noticed that the build time of U-Boot was not updated on every compile which occassionally threw me for a loop as to whether a new U-Boot binary was programmed, etc. This patch updates aU_BOOT_DATEdefine on every compile which can then be used in place of the multiple "__DATE__-__TIME__" preprocessor macros that are currently used.
this text probably belongs in the commit message above your SOB. But I still don't understand why __TIME__ didn't work for you..can you elaborate?
Kim
RFC PATCH 1/1 Update U-Boot's build timestamp on every compile
Hi Kim,
Quoted 12 lines
Quoted 11 lines
Use the GNU 'date' command to auto-generate a new U-Boot timestamp on every compile.
Signed-off-by Peter Tyser <[email protected]>---
I noticed that the build time of U-Boot was not updated on every compile which occassionally threw me for a loop as to whether a new U-Boot binary was programmed, etc. This patch updates aU_BOOT_DATEdefine on every compile which can then be used in place of the multiple "__DATE__-__TIME__" preprocessor macros that are currently used.
Quoted 3 lines
this text probably belongs in the commit message above your SOB. But I still don't understand why
__TIME__didn't work for you..can you elaborate?
__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:
U-Boot 1.3.4 (Aug 7 2008 - 12:32:20)
CPU: 8572E, Version: 1.0, (0x80e80010)
....
the code really may not have been compiled on Aug 7th, it could have been compiled today, yesterday, etc.
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 computer using hexdump, etc. The RFC/PATCH I submitted made this change for the 85xx platform as an example - other uses of __TIME__ and __DATE__ would be similarly updated in a formal patch.
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 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.
Best,
Peter
RFC PATCH 1/1 Update U-Boot's build timestamp on every compile
Dear Peter Tyser,
Quoted 11 lines · In message <1224554522.11401.28.camel@ptyser-laptop> you wrote:
Quoted 4 lines
this text probably belongs in the commit message above your SOB. But I still don't understand why
__TIME__didn't work for you..can you elaborate?
__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 asstart.Swould 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. And I can (at least theoretically) manage to build two completely different versions at the same time...
Quoted 1 line
U-Boot 1.3.4 (Aug 7 2008 - 12:32:20)
...
Quoted 2 lines
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).
Quoted 3 lines
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.
Quoted 2 lines
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).
Quoted 3 lines
the build time were printed in
common/lcd.c, it would not be identical to the time printed on the serial port sincelcd.cwas not compiled at the same time ascpu/mpc8xx/start.S.
If you care about reliable version information, use the git based ID strings.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Vulcans believe peace should not depend on force. -- Amanda, "Journey to Babel", stardate 3842.3
RFC PATCH 1/1 Update U-Boot's build timestamp on every compile
Hi Wolfgang,
Quoted 10 lines
Quoted 6 lines
__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 asstart.Swould 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.
Quoted 11 lines
Quoted 2 lines
U-Boot 1.3.4 (Aug 7 2008 - 12:32:20)
...
Quoted 2 lines
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
Quoted 4 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 9 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
the build time were printed in
common/lcd.c, it would not be identical to the time printed on the serial port sincelcd.cwas not compiled at the same time ascpu/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
RFC PATCH 1/1 Update U-Boot's build timestamp on every compile
Quoted 1 line · Peter Tyser
Hi Wolfgang,
[big snip]
Quoted 10 lines
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
Quoted 5 lines
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
+1
Call me old fashioned, but I like time/date stamps. They are more meaningful to me as a quick "did I really load a new u-boot" or "when did I do *that*" than a git hash.
Cost: $0.00. Benefit: $0.02. Benefit/Cost = priceless.
FWIIW,
gvb
RFC PATCH 1/1 Update U-Boot's build timestamp on every compile
Dear Jerry Van Baren,
Quoted 3 lines · In message <[email protected]> you wrote:
Quoted 3 lines
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.
...
Quoted 4 lines
+1
Call me old fashioned, but I like time/date stamps. They are more meaningful to me as a quick "did I really load a new u-boot" or "when did I do *that*" than a git hash.
Note that I'm not against this in principle. But if it gets changed, then not only for a single architecture, but everywhere.
Quoted 1 line
Cost: $0.00. Benefit: $0.02. Benefit/Cost = priceless.
Cost: work to implement, review and test. Benefit: $0.02. Benefit/Cost = small ;-)
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "The whole world is about three drinks behind." - Humphrey Bogart
RFC PATCH 1/1 Update U-Boot's build timestamp on every compile
Hi Wolfgang,
Quoted 7 lines
Note that I'm not against this in principle. But if it gets changed, then not only for a single architecture, but everywhere.
Quoted 1 line
Cost: $0.00. Benefit: $0.02. Benefit/Cost = priceless.
Cost: work to implement, review and test. Benefit: $0.02. Benefit/Cost = small ;-)
This PATCH/RFC was only meant as a quick example per the original email comments. It sounds like the patch would be worthwhile (let me know if I'm mistaken) so I'll go ahead and create a proper patch updating __TIME__/__DATE__ where relevant.
Thanks,
Peter
RFC PATCH 1/1 Update U-Boot's build timestamp on every compile
In reply to Peter TyserQuoted 11 lines · Peter Tyser
Quoted 6 lines
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.
Happend to me a few times as well. So I like your patch.
Quoted 13 lines
Quoted 6 lines
Quoted 3 lines
the build time were printed in
common/lcd.c, it would not be identical to the time printed on the serial port sincelcd.cwas not compiled at the same time ascpu/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):
Quoted 6 lines
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.
As mentioned above, I think your patch is an improvement. So why not accept it?
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
RFC PATCH 1/1 Update U-Boot's build timestamp on every compile
Dear Stefan Roese,
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines
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.
As mentioned above, I think your patch is an improvement. So why not accept it?
Because it changes one place and leaves 43 other, identical places unchanged.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is better to marry than to burn.
- Bible ``I Corinthians'' ch. 7, v. 9RFC PATCH 1/1 Update U-Boot's build timestamp on every compile
In reply to Peter TyserDear Peter Tyser,
Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 4 lines
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.
The *code* will be exactly the same. The binary images may differ in some strings, but the code is still the same.
But actually you just confirmed my argumnt.
Quoted 7 lines
Quoted 4 lines
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.
Indeed. Which tells you that it is a bad idea to ship any binaries with uncommitted modifications in your tree.
Hey, we can only provide the best environment for a sane development process. If you don't play by the rules you are then not exactly in a good position to complain. Talk to your QA manager, if you doubt my words ;-)
Quoted 6 lines
Quoted 2 lines
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.
You must be doing something awfully wrong when you have uncommited changes in any form of software you're releasing.
Quoted 1 line
I use git, but its version strings only change when commits occur. I
Thisis intentional - commits are the only way to change the code. Anything between commits is work in progress which you never should release to anybody, not even your bst friends.
Quoted 2 lines
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.
We take great care to generate a useful version ID string that really gets updated as soon as one of the files changes. The fact that we apend the __DATE__ and __TIME__ output to the boot messages is just for informational purposes (and a relict from earlier times, when git did not exist yet).1s
Note that there are more than 40 places in the code where __DATE__ and/or __TIME__ get used, in different ways. If you want to put more meaning into these strings than we have now, you will have to address all these use cases.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Being schizophrenic is better than living alone.
RFC PATCH 1/1 Update U-Boot's build timestamp on every compile
Quoted 6 lines · Wolfgang Denk
Dear Peter Tyser,
Quoted 3 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
I do, but the minor annoyance of having the exact same version string/time stamp for different code still exists for uncommited changes.
You must be doing something awfully wrong when you have uncommited changes in any form of software you're releasing.
I don't think he's wanting this as much for releases (which would be fine with the git id as you mentioned), but during the development process. It is very useful during development to have a timestamp which confirms that what you are running now is what you expect. There are various ways I have used this:
* Catch that I failed to copy the new image to my tftp directory
* Confirm that I'm booting from the flash bank I just programmed
* Helpful for figuring out which of the files in my tftp directory corresponds to what's running
Also, while I can see good arguments for not having a time stamp, having one that is not up-to-date seems totally useless. The stamp might not be updated for months, and thus provides only an indicator as to when the date was last updated.
Upshot: I endorse this patch's concept, and urge Peter to put in his (apparently underpaid) time to complete it. :)
Andy
RFC PATCH 1/1 Update U-Boot's build timestamp on every compile
Hi Andy,
Quoted 10 lines
I don't think he's wanting this as much for releases (which would be fine with the git id as you mentioned), but during the development process. It is very useful during development to have a timestamp which confirms that what you are running now is what you expect. There are various ways I have used this:
* Catch that I failed to copy the new image to my tftp directory
* Confirm that I'm booting from the flash bank I just programmed
* Helpful for figuring out which of the files in my tftp directory corresponds to what's running
100% agree - all our releases are generated from fully-committed git trees with tags. This patch only intends to improve development.
Quoted 7 lines
Also, while I can see good arguments for not having a time stamp, having one that is not up-to-date seems totally useless. The stamp might not be updated for months, and thus provides only an indicator as to when the date was last updated.
Upshot: I endorse this patch's concept, and urge Peter to put in his (apparently underpaid) time to complete it. :)
I'll submit a patch shortly. I'll also mention the underpaid comment to management and see what comes of that;)
Peter