Notes
(0017486) Alex Neundorf (developer) 2009-09-14 16:17	This is done before cmake looks at the compiler at all. Right now it simply uses the value of the environment variable PROCESSOR_ARCHITECTURE. Do you have a better idea what to do ? What would you expect as result ? (I mean, it's not completely wrong) What do you want to do with it ? Maybe there's another way to do it. Alex

(0017643) Rolf Eike Beer (developer) 2009-09-19 12:20	We have a project that includes libraries for some target platforms. They are then installed to different subdirectories: Windows/IA32 Windows/AMD64 Linux/IA32 Linux/AMD64 Linux/whatever ... So I need to find out which architecture I'm building for to know where I should put this. Currently I need to do: IF (CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64" OR CMAKE_CL_64) Which is also sort of wrong as it doesn't work reliable when using Visual Studio in Win64 mode, IIRC CMAKE_CL_64 isn't set then. I'll double check next week if that's still the case or if that works. See also bug 7866 for similar problems.

(0017764) Alex Neundorf (developer) 2009-09-26 03:35	Checking whether CMAKE_SIZEOF_VOID_P gives you the size of a void* pointer, you can use this for detecting whether you are doing a 32bit or 64bit build. Alex

(0017769) Rolf Eike Beer (developer) 2009-09-26 06:05	Which works for Windows platforms currently as they only support those processors, but that is basically what I'm doing now. The point is: there shouldn't be any special case be needed for Windows at all. I just want to know inside CMake which processor I'm compiling for. If I start adding FooBSD to supported platforms and those call the processor architectures different to what Linux does it shouldn't be necessary to add a special case just to get that right. That mapping should be done inside CMake as that probably knows all those platform stuff anyway. No need for every user to reinvent the wheel.

(0017770) Rolf Eike Beer (developer) 2009-09-26 06:07	Oh, by the way, pointer size doesn't help me to get the difference between amd64 and ia64, both are supported by Windows. That would add more logic to every IF().

(0017772) Alex Neundorf (developer) 2009-09-26 10:43	Maybe cmake is less advanced regarding the variables CMAKE_[HOST]_SYSTEM_PROCESSOR than you think. Also on Linux (and every other Unix) both are always the same, holding the value of the machine they run on (using uname). The only exception is when cross compiling. In this case CMAKE_SYSTEM_PROCESSOR is empty, except if it has been set explicitely in the toolchain file. So, at least your issue is not Windows specific. Alex

(0017773) Rolf Eike Beer (developer) 2009-09-26 12:04	Compiling for Win64 on Win32 is sort of cross compiling, isn't it? ;)

(0018253) Alex Neundorf (developer) 2009-10-27 16:20	Just as a note on how CMAKE_SYSTEM_PROCESSOR is currently used: CMAKE_SYSTEM_PROCESSOR is basically unused by cmake itself, AFAIK the only use is when it is used as additional suffix when loading the platform/compiler files. Also the cross compiling howto advices to set it to arbitrary strings depending on what is useful for the cross compiled project (e.g. "xscale270-sensorboard-rev3"), so for different revisions of the embedded hardware different platform files with specific necessary settings can be loaded. Alex

(0018903) David Cole (manager) 2009-12-15 13:59	The variable CMAKE_SYSTEM_PROCESSOR is behaving exactly as documented: from http://cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_SYSTEM_PROCESSOR [^] : "CMAKE_SYSTEM_PROCESSOR: The name of the CPU CMake is building for. On systems that support uname, this variable is set to the output of uname -p, on windows it is set to the value of the environment variable PROCESSOR_ARCHITECTURE." The problem here is that sometimes the host processor and the target processor are different even when you are not "cross-compiling" and using a toolchain file... If you have a better suggestion for a reliable way to detect the target processor, perhaps inventing a new variable to represent that, and setting it in the appropriate locations would be better than changing this existing variable... Also, consider the fact that on Mac OSX, there are universal binaries consisting of multiple architectures simultaneously. In that case, CMAKE_SYSTEM_PROCESSOR is fairly useless for making any decisions anyhow... Please re-open for further discussion if you think there's anything left to discuss on this issue. A suggested patch for implementing your desired behavior (and a test that verifies it behaves as expected on all of CMake's target platforms) would also be helpful.

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

Issue History
Date Modified	Username	Field	Change
2009-05-26 09:41	Rolf Eike Beer	New Issue
2009-09-14 12:44	Bill Hoffman	Status	new => assigned
2009-09-14 12:44	Bill Hoffman	Assigned To	=> Alex Neundorf
2009-09-14 16:17	Alex Neundorf	Note Added: 0017486
2009-09-19 12:20	Rolf Eike Beer	Note Added: 0017643
2009-09-26 03:35	Alex Neundorf	Note Added: 0017764
2009-09-26 06:05	Rolf Eike Beer	Note Added: 0017769
2009-09-26 06:07	Rolf Eike Beer	Note Added: 0017770
2009-09-26 10:43	Alex Neundorf	Note Added: 0017772
2009-09-26 12:04	Rolf Eike Beer	Note Added: 0017773
2009-10-14 18:17	Alex Neundorf	Summary	CMAKE_SYSTEM_PROCESSOR is not set correctly when compiling for Win64 on Win32 host => Use information from the compiler for setting CMAKE_SYSTEM_PROCESSOR (e.g. Win64 vs. Win32)
2009-10-27 16:20	Alex Neundorf	Note Added: 0018253
2009-11-22 05:11	Alex Neundorf	Assigned To	Alex Neundorf => David Cole
2009-12-15 13:42	David Cole	Relationship added	related to 0007866
2009-12-15 13:59	David Cole	Note Added: 0018903
2009-12-15 13:59	David Cole	Status	assigned => resolved
2009-12-15 13:59	David Cole	Resolution	open => won't fix
2010-12-14 18:49	David Cole	Note Added: 0024055
2010-12-14 18:49	David Cole	Status	resolved => closed