(0014071)
Bill Hoffman (manager)
2008-11-08 17:35

Looks like this info comes from kwsys/SystemInformation.cxx.

(0017167)
Rolf Eike Beer (developer)
2009-08-20 10:44

Honestly, I think things are broken in there for Win64. Other 64 bit
platforms are also affected on parts of this.

For example SystemInformationImplementation::Is64Bits(): it does not
return if the platform is 64 bit or not but just if the cmake binary was
compiled for 32 or 64 bit. Since there is usually no problem in running
a 32 bit binary in a 64 bit environment this will just give wrong
results. Windows is a especially hard candidate here as there is no 64
bit installer available for download so people will probably use the 32
bit version everywhere.

SystemInformationImplementation::QueryOSInformation() even has a local
variable "BOOL bIsWindows64Bit;" which is set correctly, but not
populated anywhere outside the local function scope and so is completely
write-only.

Then SzstemInformationImplementation::OSPlatform: this is never
initialized for Windows. The most simple version would just be
getenv("PROCESSOR_ARCHITECTURE") but there is certainly a better way.
For example using the wProcessorArchitecture member of the SYSTEM_INFO
struct as used in SystemInformationImplementation::CPUCount().

(0017171)
Rolf Eike Beer (developer)
2009-08-21 08:28

This diff at least adds the platform information on Windows. It is designed to give results to Linux as similar as possible: if the kernel is compiled for anything before PentiumIII (i.e. everything older than Vista) the result is "i586", else "i686". If it's 64 bit Windows the result is "x86_64", if it's Itanium "ia64". The last one I'm not really sure of as I don't have such a system here.

Regarding SystemInformationImplementation::Is64Bits(): what should be returned here is the pointer size of the used _compiler_ as this is the only way to find out what we are working with in that project (which might be 32-on-64) and not what the system supports. The only case where this information is always right is when the system itself only supports 32 bit ...

(0019266)
Rolf Eike Beer (developer)
2010-01-22 08:36

This should improve the situation for CDash at least a bit:

-when the generator is "NMake Makefiles" don't only use "nmake" as DART_CXX_NAME but also append a string about the corresponding MSVC version (taken from MSVC_VERSION) [hunks 1 and 3]

-if the build is either "NMake Makefiles" with CMAKE_CL_64 set or a generator that ends with " Win64" then set the platform name to "Win64" instead of "Win32" [hunk 2]

The patch is against 2.8.0.

(0020754)
Rolf Eike Beer (developer)
2010-05-17 04:15

Patch updated to also show the info for "NMake Makefiles JOM" builds.

(0021195)
Bill Hoffman (manager)
2010-06-30 08:53

ELSEIF(DART_CXX_NAME MATCHES "nmake" OR DART_CXX_NAME MATCHES "jom")

That won't work....

The generator name is NMake Makefiles not nmake, also the jom one has NMake in the name now so no need for an OR. Are these patches being tested??

(0021198)
Rolf Eike Beer (developer)
2010-06-30 09:59

Yes, of course. I match against DART_CXX_NAME, not GENERATOR here.

(0021199)
Bill Hoffman (manager)
2010-06-30 10:20

OK, hmm... Would be better to base this on the generator.... Build tools come and go... For example Visual Studio 10 uses msbuild and not msdeve or devenv... People could also use some sort of wrapper script.

(0021200)
Rolf Eike Beer (developer)
2010-06-30 10:35

Should equally work with

ELSEIF (CMAKE_GENERATOR MATCHES "NMake Makefiles" OR CMAKE_GENERATOR MATCHES "NMake Makefiles JOM")

then, but I'm not in the office this week and can't test this.

(0021201)
Bill Hoffman (manager)
2010-06-30 10:45

No need for the OR, as the first part of NMake Makefiles will match for either. That was intentional in the naming of the jom generator so that it would not require special cases in projects.

(0021204)
Rolf Eike Beer (developer)
2010-07-01 06:14

Yes, of course. I was thinking "STREQUAL" and writing "MATCHES".

(0021957)
David Cole (manager)
2010-08-25 12:50

I'm going to resolve this as "won't fix" because Is64Bits is an ambiguous field. It is not clear if it is supposed to be a reflection of the OS on which you are running, the architecture of the driving ctest or the architecture of some executable that was built in the process of running the dashboard.

See a more in-depth analysis of why "Is64Bits" is a useless field here:
http://public.kitware.com/pipermail/cdash/2010-August/000849.html [^]

We need a better definition of what's what. Changing the meaning of Is64Bits from one thing to another is not going to help the situation.

(0024098)
David Cole (manager)
2010-12-14 18:50

Closing bugs that have been resolved for more than 3 months without any further updates.

Issue History
Date Modified	Username	Field	Change
2008-10-28 04:19	Rolf Eike Beer	New Issue
2008-11-08 17:35	Bill Hoffman	Note Added: 0014071
2008-11-08 17:36	Bill Hoffman	Status	new => assigned
2008-11-08 17:36	Bill Hoffman	Assigned To	=> Julien Jomier
2009-08-20 10:44	Rolf Eike Beer	Note Added: 0017167
2009-08-21 08:22	Rolf Eike Beer	File Added: cmake_sysinfo_windows.diff
2009-08-21 08:28	Rolf Eike Beer	Note Added: 0017171
2009-12-11 13:21	David Cole	Relationship added	related to 0010037
2009-12-15 13:42	David Cole	Relationship added	related to 0009065
2010-01-22 08:36	Rolf Eike Beer	Note Added: 0019266
2010-01-22 08:36	Rolf Eike Beer	File Added: nmake.diff
2010-05-17 04:14	Rolf Eike Beer	File Added: 0001-Show-more-information-about-the-compiler-on-Windows-.patch
2010-05-17 04:15	Rolf Eike Beer	Note Added: 0020754
2010-06-30 08:53	Bill Hoffman	Note Added: 0021195
2010-06-30 09:59	Rolf Eike Beer	Note Added: 0021198
2010-06-30 10:20	Bill Hoffman	Note Added: 0021199
2010-06-30 10:35	Rolf Eike Beer	Note Added: 0021200
2010-06-30 10:45	Bill Hoffman	Note Added: 0021201
2010-07-01 06:14	Rolf Eike Beer	Note Added: 0021204
2010-08-25 12:50	David Cole	Note Added: 0021957
2010-08-25 12:50	David Cole	Status	assigned => resolved
2010-08-25 12:50	David Cole	Resolution	open => won't fix
2010-08-31 18:13	David Cole	Target Version	=> CMake 2.8.3
2010-12-14 18:50	David Cole	Note Added: 0024098
2010-12-14 18:50	David Cole	Status	resolved => closed

Notes
(0014071) Bill Hoffman (manager) 2008-11-08 17:35	Looks like this info comes from kwsys/SystemInformation.cxx.

(0017167) Rolf Eike Beer (developer) 2009-08-20 10:44	Honestly, I think things are broken in there for Win64. Other 64 bit platforms are also affected on parts of this. For example SystemInformationImplementation::Is64Bits(): it does not return if the platform is 64 bit or not but just if the cmake binary was compiled for 32 or 64 bit. Since there is usually no problem in running a 32 bit binary in a 64 bit environment this will just give wrong results. Windows is a especially hard candidate here as there is no 64 bit installer available for download so people will probably use the 32 bit version everywhere. SystemInformationImplementation::QueryOSInformation() even has a local variable "BOOL bIsWindows64Bit;" which is set correctly, but not populated anywhere outside the local function scope and so is completely write-only. Then SzstemInformationImplementation::OSPlatform: this is never initialized for Windows. The most simple version would just be getenv("PROCESSOR_ARCHITECTURE") but there is certainly a better way. For example using the wProcessorArchitecture member of the SYSTEM_INFO struct as used in SystemInformationImplementation::CPUCount().

(0017171) Rolf Eike Beer (developer) 2009-08-21 08:28	This diff at least adds the platform information on Windows. It is designed to give results to Linux as similar as possible: if the kernel is compiled for anything before PentiumIII (i.e. everything older than Vista) the result is "i586", else "i686". If it's 64 bit Windows the result is "x86_64", if it's Itanium "ia64". The last one I'm not really sure of as I don't have such a system here. Regarding SystemInformationImplementation::Is64Bits(): what should be returned here is the pointer size of the used _compiler_ as this is the only way to find out what we are working with in that project (which might be 32-on-64) and not what the system supports. The only case where this information is always right is when the system itself only supports 32 bit ...

(0019266) Rolf Eike Beer (developer) 2010-01-22 08:36	This should improve the situation for CDash at least a bit: -when the generator is "NMake Makefiles" don't only use "nmake" as DART_CXX_NAME but also append a string about the corresponding MSVC version (taken from MSVC_VERSION) [hunks 1 and 3] -if the build is either "NMake Makefiles" with CMAKE_CL_64 set or a generator that ends with " Win64" then set the platform name to "Win64" instead of "Win32" [hunk 2] The patch is against 2.8.0.

(0020754) Rolf Eike Beer (developer) 2010-05-17 04:15	Patch updated to also show the info for "NMake Makefiles JOM" builds.

(0021195) Bill Hoffman (manager) 2010-06-30 08:53	ELSEIF(DART_CXX_NAME MATCHES "nmake" OR DART_CXX_NAME MATCHES "jom") That won't work.... The generator name is NMake Makefiles not nmake, also the jom one has NMake in the name now so no need for an OR. Are these patches being tested??

(0021198) Rolf Eike Beer (developer) 2010-06-30 09:59	Yes, of course. I match against DART_CXX_NAME, not GENERATOR here.

(0021199) Bill Hoffman (manager) 2010-06-30 10:20	OK, hmm... Would be better to base this on the generator.... Build tools come and go... For example Visual Studio 10 uses msbuild and not msdeve or devenv... People could also use some sort of wrapper script.

(0021200) Rolf Eike Beer (developer) 2010-06-30 10:35	Should equally work with ELSEIF (CMAKE_GENERATOR MATCHES "NMake Makefiles" OR CMAKE_GENERATOR MATCHES "NMake Makefiles JOM") then, but I'm not in the office this week and can't test this.

(0021201) Bill Hoffman (manager) 2010-06-30 10:45	No need for the OR, as the first part of NMake Makefiles will match for either. That was intentional in the naming of the jom generator so that it would not require special cases in projects.

(0021204) Rolf Eike Beer (developer) 2010-07-01 06:14	Yes, of course. I was thinking "STREQUAL" and writing "MATCHES".

(0021957) David Cole (manager) 2010-08-25 12:50	I'm going to resolve this as "won't fix" because Is64Bits is an ambiguous field. It is not clear if it is supposed to be a reflection of the OS on which you are running, the architecture of the driving ctest or the architecture of some executable that was built in the process of running the dashboard. See a more in-depth analysis of why "Is64Bits" is a useless field here: http://public.kitware.com/pipermail/cdash/2010-August/000849.html [^] We need a better definition of what's what. Changing the meaning of Is64Bits from one thing to another is not going to help the situation.

(0024098) David Cole (manager) 2010-12-14 18:50	Closing bugs that have been resolved for more than 3 months without any further updates.