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

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

[Peter Tyser]

Use the GNU 'date' command to auto-generate a new U-Boot
timestamp on every compile.

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
---
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(-)

diff --git a/Makefile b/Makefile
index c711df6..2c76003 100644
--- a/Makefile
+++ b/Makefile
@@ -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))' \
 		 ) > $@.tmp
+		@( printf '#define U_BOOT_DATE "%s"\n' '$(shell date +"%b %d %C%y - %T")' \
+		 ) >> $@.tmp
 		@cmp -s $@ $@.tmp && rm -f $@.tmp || mv -f $@.tmp $@
 
 gdbtools:
diff --git a/cpu/mpc85xx/start.S b/cpu/mpc85xx/start.S
index 25d0390..dc55700 100644
--- a/cpu/mpc85xx/start.S
+++ b/cpu/mpc85xx/start.S
@@ -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
-- 
1.6.0.2.GIT

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

[Peter Tyser]

On Fri, 2008-10-17 at 17:51 -0500, Peter Tyser wrote:
> Use the GNU 'date' command to auto-generate a new U-Boot
> timestamp on every compile.
> 
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> ---
> 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.

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

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

[Kim Phillips]

On Fri, 17 Oct 2008 17:51:21 -0500
Peter Tyser <ptyser@xes-inc.com> wrote:

> Use the GNU 'date' command to auto-generate a new U-Boot
> timestamp on every compile.
> 
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> ---
> 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 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

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

[Peter Tyser]

Hi Kim,

> > Use the GNU 'date' command to auto-generate a new U-Boot
> > timestamp on every compile.
> > 
> > Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> > ---
> > 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 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

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

[Wolfgang Denk]

Dear Peter Tyser,

In message <1224554522.11401.28.camel@ptyser-laptop> you wrote:
>
> > 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:

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

> 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).

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

> 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).

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

Best regards,

Wolfgang Denk

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

[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

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

[Jerry Van Baren]

Peter Tyser wrote:
> Hi Wolfgang,

[big snip]

> 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

+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

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

[Stefan Roese]

On Tuesday 21 October 2008, Peter Tyser wrote:
> > 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.

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

As mentioned above, I think your patch is an improvement. So why not accept 
it?

Acked-by: Stefan Roese <sr@denx.de>

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

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

[Wolfgang Denk]

Dear Peter Tyser,

In message <1224600029.18428.339.camel@localhost.localdomain> you wrote:
> 
> > 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.

> > 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 ;-)

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

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

> 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

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

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

[Wolfgang Denk]

Dear Jerry Van Baren,

In message <48FDEC8D.6010502@ge.com> you wrote:
>
> > 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.
...
> +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.

> 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

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

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

[Wolfgang Denk]

Dear Stefan Roese,

In message <200810211657.06019.sr@denx.de> you wrote:
>
> > 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

-- 
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. 9

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

[Peter Tyser]

Hi Wolfgang,

> Note that I'm not against this in principle. But if it gets changed,
> then not only for a single architecture, but everywhere.
> 
> > 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

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

[Andy Fleming]

On Tue, Oct 21, 2008 at 9:59 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Peter Tyser,
>

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


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

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

[Peter Tyser]

Hi Andy,

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

> 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