[U-Boot-Users] keeping build date and time up to date

I was looking at how U-Boot gets the date and time in the version string and I noticed that it doesn't get updated for each build. I'm using an arm-based board, and the code for building the version_string variable is in lib_arm/board.c. In other words, the date and time only get updated when that file (or anything it depends on) changes.
There's similar code in other lib*/board.c files.
I'm attaching a patch that builds the entire version string (including date and time) just before linking U-Boot so it's always up to date. Key features of the patch are:
1. Makefile generates version info in version_autogenerated.c, not include/version_autogenerated.h. I did this to avoid recompiling everything that depends on version.h since it changes every time.
2. There's no separate version recipe in Makefile since that caused a relink every time.
3. version.h now is C specific -- assembly files can no longer include it.
4. I deal with CONFIG_IDENT_STRING with a small program tools/identstr that I run from Makefile. I did this to avoid generating version_string at runtime with either a fixed size buffer that might not be big enough, or with malloc.
This patch is incomplete though. I'm sending it because I'm curious if this is interesting to other people (and they agree with the approach) and because I have some questions about how to proceed. They are:
- Lots of .S files include version.h but don't seem like they need to. I believe I can take them out without changing behavior.
- Lots of .S files have code like this: .globl version_string version_string: .ascii U_BOOT_VERSION .ascii " (", __DATE__, " - ", __TIME__, ")" .ascii CONFIG_IDENT_STRING, "\0"
I believe I can take these out as well.
I could use confirmation on both of these items.
- The blackfin board does something special with the version string. I'm sure I can come up with something equivalent but I wanted to get the above worked out first.
Thanks for your input.
-DB

In message 030701c6d8fc$ca4f9850$7934800a@RudiDell you wrote:
I was looking at how U-Boot gets the date and time in the version string and I noticed that it doesn't get updated for each build. I'm using an arm-based
Who says it should?? ;-)
I'm attaching a patch that builds the entire version string (including date and time) just before linking U-Boot so it's always up to date. Key features of the patch are:
...
-VERSION_FILE = $(obj)include/version_autogenerated.h +VERSION_FILE = version_autogenerated.c
Here you ruin the new support for building in a different directory. Check you patch for other, similar issues.
Also, all of this looks overly complicated to me. If the time stamp is important to you, run a "make clean" first ;-)
Best regards,
Wolfgang Denk

On Friday, September 15, 2006 @ 3:50p, Wolfgang Denk wrote:
In message 030701c6d8fc$ca4f9850$7934800a@RudiDell you wrote:
I was looking at how U-Boot gets the date and time in the version string and I noticed that it doesn't get updated for each build. I'm using an arm-based
Who says it should?? ;-)
Ummmm....me. :)
-VERSION_FILE = $(obj)include/version_autogenerated.h +VERSION_FILE = version_autogenerated.c
Here you ruin the new support for building in a different directory.
You're right. It should be $(obj)version_autogenerated.c
Check you patch for other, similar issues.
I didn't find any. If you know of some more, I'd love to hear about them.
Also, all of this looks overly complicated to me.
I agree. I think it's the CONFIG_IDENT_STRING support (w/ the extra program in tools) that makes it complicated. If other folks have solutions to this, I'm interested. There are enough references to CONFIG_IDENT_STRING in the code that removing it seems like a no-go.
The rest of it seems pretty straightforward though.
I'm hoping that centralizing the version stuff so individual boards don't have to worry about it justifies the complexity. That and having a correct date/time. :)
It also seems like just leaving version_string and removing the U_BOOT_VERSION preprocessor symbol might further simplify things.
If the time stamp is important to you, run a "make clean" first ;-)
Here's hoping the smiley face is strong enough that you'll consider accepting a patch so the time stamp is correct without having to clean first. :)
Thanks much.
-DB
participants (2)
-
David Byron
-
Wolfgang Denk