Proper way to reference build date (a la __DATE__)

[courtarro]

I'd like to include the build date of my app in its About box. Unfortunately the About box class is only compiled whenever it is changed, thus the value of __DATE__ that it uses is frozen even as I make changes elsewhere in the app. When the final app is compiled and linked, the About box's OBJ file is always up-to-date, thus the build date is not updated within it.

I could make a preprocessor action that "touches" the About box's source file, thus forcing it to recompile each time, but this About box is used by several different binary projects. I don't want VS to recompile all of my binaries each time I do a batch compile just to update the build date.

Basically I want the build date to be updated anytime a new binary is created and linked, but not otherwise. Does anyone have a suggestion as to how I can achieve this?

P.S. I don't want to use the EXE's file modification date because that changes whenever the file is downloaded, sent via email, etc. I need the build date to stay fixed for maintenance purposes.

 

[Salem]

Use a pre-build step to regenerate a source file which contains only 1 line of code.

Namely an initialised char array containing the date/time of the build.

Your about box code just references this as an extern symbol.


--
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.

 

[courtarro]

That's close, but I believe it would cause the build process to re-link all binaries even if they had no other changes (and thus didn't really need to be re-linked). I worry about this situation for two reasons:

1. I have a bunch of binaries (EXEs) that will be created when I do a batch compile. This can take quite a long time if they all have to re-link every single time.

2. Two binaries may make it into the real world with absolutely no differences except their build date. A changed build date implies changes elsewhere, and that makes it hard to keep up with revisions in the field.

To be honest, these are tiny OCD-type points, but I was hoping to find a good solution that does exactly what I want. I'm hoping for some discussion to find the perfect way. Still, I came up with one potential solution that is not very graceful but provides the exact desired behavior:

1. Include a preset string in the file, such as "###BUILDDATETIME###"

2. In a post-linker step, call a small widget that searches your binary for that string and replaces it with the actual build date. Of course it would have to be the exact same size, but the string above matches the form "00/00/0000 00:00:00". This could get tricky under certain circumstances, but it seems straightforward in my very limited tests.

Anyway, I'll keep playing with it. Thanks for the suggestion.

 

[Salem]

> This can take quite a long time if they all have to re-link every single time.
How often are you doing releases that such a thing would be a problem?
Besides, if it's that long then you plan your work accordingly so that it happens over lunch, or overnight.

For me, a release (to customer, or another team) means at least:
- Absolutely everything checked into a source control system, and labelled.
- A "rebuild all" from a clean directory structure.
- A release test on everything, and the results checked back into source control.

Incremental builds can and do screw up from time to time. If that causes a bug, you will not be able to replicate it.

> Two binaries may make it into the real world with absolutely no differences except their build date.
As opposed to two binaries with real differences which have the same date.
IMO, your attempts to excessively optimise this can only lead to that scenario at some point.

Or instead of date, just have a "build number" which just increments every time you do a "rebuild all". If you make that part of your release procedure, then anyone on the outside at least will always see a consistent set.

--
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.