×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Proper way to reference build date (a la __DATE__)

Proper way to reference build date (a la __DATE__)

Proper way to reference build date (a la __DATE__)

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

RE: Proper way to reference build date (a la __DATE__)

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.

RE: Proper way to reference build date (a la __DATE__)

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

RE: Proper way to reference build date (a la __DATE__)

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

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close