User forums > Help
Start page - wrong build date & time
troels:
--- Quote from: thomas on April 20, 2006, 03:29:53 pm ---Build times come from the standard C predefined __DATE__ and __TIME__ macros, and are thus only updated when the respective source is recompiled.
--- End quote ---
The real build time is the link time rather than the compile time.
On Windows you dig out the link time from the coff exe header: IMAGE_FILE_HEADER.TimeDateStamp (time_t).
EDIT: At runtime naturally, not compile time.
On Linux...?
/Troels
thomas:
--- Quote from: troels on April 20, 2006, 11:29:37 pm ---The real build time is the link time rather than the compile time.
On Windows you dig out the link time from the coff exe header: IMAGE_FILE_HEADER.TimeDateStamp (time_t).
EDIT: At runtime naturally, not compile time.
On Linux...?
--- End quote ---
No way, sorry. That would mean to implement separate codepaths for Windows, Linux, BSD, Solaris, MacOS and what. This does not even take into account that some of these operating systems can have several different binary formats. My dear Horatio, there is more than PE and ELF on this world. All that for such a sophistry?
Using a compiler constant, on the other hand, works everywhere and needs no additional code whatsoever.
The primary intent of the build date/time is that if at some point in the future, someone posts "Version 1.0 revision 2587 (gcc 3.4.5 Windows/unicode, build: Jun 18 2006 14:57:48)" then we can see "Ah, he is using last week's official build". We don't need to remember which revision that was.
I have modified the build time string on my working copy so it always shows the time of the first rebuild after the last update. This is what makes most sense, and it is the only thing that is feasible, too. So far it looks OK, if no problems occur, I'll commit that tonight.
If we want really accurate build times, we have to mark one file "dirty" for every build. This, however, is not a valid option, as it would mean to first relink the SDK, then the application, and then all plugins1 (which may take 20-40 seconds, depending on your PC's speed) only to update a completely insignificant timestamp in an otherwise unmodified source tree.
That is an outrageous amount of time and thus prohibitive - I would rather remove the timestamp alltogether than go that way. Remember that the developers do more than 50 rebuilds per day. We cannot and will not relink half of the application every time, that would be pure madness.
On the other hand, having the timestamp updated at the same time as the revision number is quite fine. Although you can of course actively cheat this system, in the normal case it will report the time of your last update plus a few minutes, which is exactly the information that is interesting. It represents the state of the sources, as taken from SVN.
1That is because the application (and plugins) link to the SDK, not the other way around.
troels:
--- Quote from: thomas on April 21, 2006, 02:43:07 pm ---No way, sorry
--- End quote ---
Does this look like a feature request to you?
--- Quote from: thomas on April 21, 2006, 02:43:07 pm ---My dear Horatio
--- End quote ---
Please again.
--- Quote from: thomas on April 21, 2006, 02:43:07 pm ---If we want really accurate build times, we have to...
--- End quote ---
One more time then, for the record:
The most "really" accurate build time, if there is to be only one, is the link time of codeblocks.exe.
troels:
--- Quote from: troels on April 21, 2006, 03:39:18 pm ---
--- Quote from: thomas on April 21, 2006, 02:43:07 pm ---My dear Horatio
--- End quote ---
Please again.
--- End quote ---
No? This is for you then:
My dear Gaylord, I have one bug report and one feature request for you, if you're not too busy painting icons:
Bug report: The first tab in the about box says "a nice programming environment offering everything he/they would ever need".
It should definitively read "everything she/he/they would ever need", or "everything s/he/they...".
Feature request: The notebook tabs in the about box would look better as wxHtmlWindow's.
Navigation
[0] Message Index
[*] Previous page
Go to full version