Start page - wrong build date & time

[Michael]

Hello,

I have just finished (around 30-40 minutes ago to build rev2366. All went fine, but then I have had a look at the start page and remarked this:

Version 1.0 revision 2366 (gcc 4.1.0 Windows/unicode, build: Apr 19 2006 01:25:14)

The date is wrong (one day backward) and the time too (one hour forward).

IIRC it worked usually.

Has someone else remarked this small issue?

Best wishes,
Michael

[PsYhLo]

Now I compile it and will see

[killerbot]

nope, this is ok in my build

[Michael]

nope, this is ok in my build

Hmm...ok.

I will keep an eye on this. Probably, just a temporary issue.

Best wishes,
Michael

[PChris]

I have this problem too...
In the about box it is correct, but at the start page it is wrong

[PsYhLo]

it's ok

[Michael]

In the about box it is correct, but at the start page it is wrong

Yes, right. In the About box date and time are correct.

Best wishes,
Michael

[killerbot]

I rechedk both :
date is the same, onlt in the time there's a little difference :
  about box : 12:27:45
  start here page : 12:28:15

so it's for sure they don't come from the same source (or better from the same moment)

[thomas]

Regarding the original question: This is normal behaviour, and it has always been like that (you only did not see it).

Regarding the times in the about box and the start here page being different: This is normal behaviour, too (and has always been like that).

Build times come from the standard C predefined __DATE__ and __TIME__ macros, and are thus only updated when the respective source is recompiled.

The release number, on the other hand, calls a SDK function which updates the release every time you compile after updating. Therefore, the build time may be wrong when the release number is still accurate.

This could be "fixed" by using a SDK function instead of those macros, but I don't see that it is really a showstopping problem. The revision number is the important part, the build time was only  intended to give us a hint when we release a build (which will be a clean build anyway), since a date is easier to memorize for a human than a revision number.

I might nevertheless "fix" it next weekend (has low priority though).

[Michael]

Regarding the original question: This is normal behaviour, and it has always been like that (you only did not see it).

Regarding the times in the about box and the start here page being different: This is normal behaviour, too (and has always been like that).

Build times come from the standard C predefined __DATE__ and __TIME__ macros, and are thus only updated when the respective source is recompiled.

The release number, on the other hand, calls a SDK function which updates the release every time you compile after updating. Therefore, the build time may be wrong when the release number is still accurate.

This could be "fixed" by using a SDK function instead of those macros, but I don't see that it is really a showstopping problem. The revision number is the important part, the build time was only  intended to give us a hint when we release a build (which will be a clean build anyway), since a date is easier to memorize for a human than a revision number.

I might nevertheless "fix" it next weekend (has low priority though).

Hello,

Thank you for the explanation. Yes, I probably did not see/remark it . Usually, I check the rev number and compiler used (especially when I test new GCC versions).

The problem is not a showstopping one. If you have some free time to fix it, IMHO it woul be good , but if you have more important things to do, then just posticipate it .

Best wishes,
Michael

[troels]

Build times come from the standard C predefined __DATE__ and __TIME__ macros, and are thus only updated when the respective source is recompiled.

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]

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

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 plugins¹ (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.

                           
¹That is because the application (and plugins) link to the SDK, not the other way around.

[troels]

No way, sorry

Does this look like a feature request to you?

My dear Horatio

Please again.

If we want really accurate build times, we have to...

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]

My dear Horatio

Please again.

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.