|
Notes |
|
|
(0014071)
|
|
Bill Hoffman
|
|
2008-11-08 17:35
|
|
|
Looks like this info comes from kwsys/SystemInformation.cxx. |
|
|
|
(0017167)
|
|
Rolf Eike Beer
|
|
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
|
|
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
|
|
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
|
|
2010-05-17 04:15
|
|
|
Patch updated to also show the info for "NMake Makefiles JOM" builds. |
|
|
|
(0021195)
|
|
Bill Hoffman
|
|
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
|
|
2010-06-30 09:59
|
|
|
Yes, of course. I match against DART_CXX_NAME, not GENERATOR here. |
|
|
|
(0021199)
|
|
Bill Hoffman
|
|
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
|
|
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
|
|
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
|
|
2010-07-01 06:14
|
|
|
Yes, of course. I was thinking "STREQUAL" and writing "MATCHES". |
|
|
|
(0021957)
|
|
David Cole
|
|
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
|
|
2010-12-14 18:50
|
|
|
Closing bugs that have been resolved for more than 3 months without any further updates. |
|
cmake_sysinfo_windows.diff (875) 2009-08-21 08:22