|
Notes |
|
|
(0031917)
|
|
Brad King
|
|
2012-12-18 08:03
|
|
|
|
|
(0031918)
|
|
jujjyl
|
|
2012-12-18 08:20
|
|
Hi, sorry for reopening, but apparently it is the only way to comment on an issue (or I did not find the proper button).
I don't think supporting Windows Phone 8 is a duplicate of supporting Windows 8 RT or Windows 8 RT for ARM. They have separate installable Visual Studio executables, separate project files (that differ by quite a lot) and separate compilers, so the support won't come automatically by implementing just support for one.
In summary, supporting WinPhone8, Win8RT for X86 and Win8RT for ARM can/could be done orthogonally as separate tasks, since they're separate toolchains. |
|
|
|
(0031920)
|
|
Brad King
|
|
2012-12-18 09:43
|
|
|
|
|
(0033543)
|
|
Paul Annetts
|
|
2013-07-15 18:38
|
|
|
I'm working on a patch for initial WP8 support (starting with static libraries). |
|
|
|
(0034613)
|
|
Moshe Rubin
|
|
2013-11-30 13:53
|
|
Considering Brad King's comments in bug 0014598, I would like to propose the following fix. I have made the fix on my system and can now generate a VS solution file for cross-compiling a Windows Phone ARM binary target on a Windows 8 host.
The fix is in the "Modules\Platform\Windows-MSVC.cmake" file, starting on line 160:
<snippet>
if(MSVC_VERSION GREATER 1310)
set(_RTC1 "/RTC1")
set(_FLAGS_CXX " /GR /EHsc")
# (30 Nov 2013): The following "if" added to prevent including windows system libraries if using an ARM generator
if(NOT "${CMAKE_GENERATOR}" MATCHES "ARM")
set(CMAKE_C_STANDARD_LIBRARIES_INIT "kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib")
endif()
else()
set(_RTC1 "/GZ")
set(_FLAGS_CXX " /GR /GX")
# (30 Nov 2013): The following "if" added to prevent including windows system libraries if using an ARM generator
if(NOT "${CMAKE_GENERATOR}" MATCHES "ARM")
set(CMAKE_C_STANDARD_LIBRARIES_INIT "kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib")
endif()
endif()
</snippet>
The fix consists of adding an "if" statement to prevent adding the windows system libraries when using an ARM-related generator under Windows. The rational is that under Windows, compiling for ARM automatically precludes any Win32-related anything, rendering kernel32.lib etc. irrelevant.
Running my test emits the following CMake output:
<snippet>
--------------------------------------------
Using CMake 2.8.12-FIXED
--------------------------------------------
-- The C compiler identification is MSVC 17.0.50727.1
-- The CXX compiler identification is MSVC 17.0.50727.1
-- Check for working C compiler using: Visual Studio 11 ARM
-- Check for working C compiler using: Visual Studio 11 ARM -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 11 ARM
-- Check for working CXX compiler using: Visual Studio 11 ARM -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/junk/TestProjects/CMakeArmRegression/Generated-2.8.12-FIXED
</snippet>
Would this fix be acceptable to the CMake team? |
|
|
|
(0034675)
|
|
Brad King
|
|
2013-12-02 10:35
|
|
|
Re 0013791:0034613: The proposed solution is along the right lines and may be correct. However I'd like to determine if there is a better way to detect the ARM case which can work when using other generators. In the WinCE code path above the code in question we check the MSVC_${lang}_ARCHITECTURE_ID detected when determining the compiler id to look for ARM platforms. Would something similar work here? |
|
|
|
(0034687)
|
|
Moshe Rubin
|
|
2013-12-03 03:43
|
|
Brad, I would like to test your idea, but am encountering what seems to be an undesired caching issue.
My version of CMake 2.8.12 is installed in the directory "C:\Program Files (x86)\CMake 2.8.12".
I attempted to modify the file "C:\Program Files (x86)\CMake 2.8.12\share\cmake-2.8\Modules\Platform\Windows-MSVC.cmake" by inserting some debugging statements at line 126:
<snippet>
[123] # default to Debug builds
[124] set(CMAKE_BUILD_TYPE_INIT Debug)
[125]
[126] #DEBUG-START
[127] message (STATUS "${lang}")
[128] message (STATUS "${MSVC_${lang}_ARCHITECTURE_ID}")
[129] #DEBUG-END
[130]
[131] if(WINCE)
[132] foreach(lang C CXX)
</snippet>
After deleting the previous Cmake-generated output folder, I reran my test case:
"C:\Program Files (x86)\CMake 2.8.12\bin\cmake.exe" ..\ -G "Visual Studio 11 ARM" -T "v110_wp80" --trace >..\foo 2>&1
Here are the relevant traced lines:
<snippet>
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(119): if(${MSVC_VERSION} GREATER 1599 )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(120): set(MSVC_INCREMENTAL_DEFAULT ON )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(124): set(CMAKE_BUILD_TYPE_INIT Debug )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(126): if(WINCE )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(157): else()
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(158): if(MSVC_VERSION GREATER 1310 )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(159): set(_RTC1 /RTC1 )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(160): set(_FLAGS_CXX /GR /EHsc )
</snippet>
There are two strange things here:
(a) I expected to see the two message(...) outputs from lines 127-128 in the above trace, but did not.
(b) The statement "if(WINCE)", which used to be on line 126, was bumped to line 131 in the altered Windows-MSVC.cmake file. In the trace, however, it is still being read from line 126! It is as if CMake is opening the modified file (as evidenced by the path in the trace line and by checking with MS's ProcMon utility) but is reading the previous contents from some cache file.
Can you please tell me how I can make a change to the Windows-MSVC.cmake file that is picked up correctly and immediately by CMake? Can you also verify that I do not need to recompile the entire cmake.exe project for the *.cmake changes to be recognized? |
|
|
|
(0034690)
|
|
Brad King
|
2013-12-03 09:03
(edited on: 2013-12-03 09:04) |
|
|
|
|
(0034704)
|
|
Moshe Rubin
|
|
2013-12-04 04:54
|
|
Brad,
First, you were spot on about being tripped up by the Windows VirtualStore feature. I can now modify the Windows-MSVC.cmake file and see the changes immediately -- thanks! <g>
Second, I inserted message() statements in Windows-MSVC.cmake to print the values of ${MSVC_${lang}_ARCHITECTURE_ID} and other variables with the aim of using it to determine whether we should include Win32 system libraries or not:
<code>
#DEBUG-START
message (STATUS "\${lang} = \"${lang}\"")
message (STATUS "\${MSVC_\${lang}_ARCHITECTURE_ID} => " "\${MSVC_${lang}_ARCHITECTURE_ID}")
message (STATUS "\${MSVC_${lang}_ARCHITECTURE_ID} = \"${MSVC_${lang}_ARCHITECTURE_ID}\"")
message (STATUS "\${MSVC_C_ARCHITECTURE_ID} = \"${MSVC_C_ARCHITECTURE_ID}\"")
message (STATUS "\${MSVC_CXX_ARCHITECTURE_ID} = \"${MSVC_CXX_ARCHITECTURE_ID}\"")
#DEBUG-END
if(WINCE)
foreach(lang C CXX)
set(_MSVC_${lang}_ARCHITECTURE_FAMILY "${MSVC_${lang}_ARCHITECTURE_ID}")
if(_MSVC_${lang}_ARCHITECTURE_FAMILY STREQUAL "THUMB")
set(_MSVC_${lang}_ARCHITECTURE_FAMILY "ARM")
elseif(_MSVC_${lang}_ARCHITECTURE_FAMILY MATCHES "^SH")
set(_MSVC_${lang}_ARCHITECTURE_FAMILY "SHx")
endif()
string(TOUPPER "${_MSVC_${lang}_ARCHITECTURE_FAMILY}" _MSVC_${lang}_ARCHITECTURE_FAMILY_UPPER)
endforeach()
. . .
</code>
Here's the build output:
<build-output>
-- The C compiler identification is MSVC 17.0.50727.1
-- The CXX compiler identification is MSVC 17.0.50727.1
-- ${lang} = ""
-- ${MSVC_${lang}_ARCHITECTURE_ID} => ${MSVC__ARCHITECTURE_ID}
-- ${MSVC__ARCHITECTURE_ID} = ""
-- ${MSVC_C_ARCHITECTURE_ID} = "ARM"
-- ${MSVC_CXX_ARCHITECTURE_ID} = "ARM"
-- Check for working C compiler using: Visual Studio 11 ARM
-- Check for working C compiler using: Visual Studio 11 ARM -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 11 ARM
-- Check for working CXX compiler using: Visual Studio 11 ARM -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/junk/TestProjects/CMakeArmRegression/Generated-2.8.12
</build-output>
This shows that ${lang} is the empty string (""), thereby preventing accessing ${MSVC_${lang}_ARCHITECTURE_ID} correctly. The variables ${MSVC_C_ARCHITECTURE_ID} and ${MSVC_CXX_ARCHITECTURE_ID}, however, are alive and kicking and can be used for our fix.
So the question is why is ${lang} not set. The only two places where <lang> is set is in:
<snippet>
Searching for: set(lang
CMake 2.8.12\share\cmake-2.8\Modules\FortranCInterface.cmake(227): set(lang C)
CMake 2.8.12\share\cmake-2.8\Modules\FortranCInterface.cmake(234): set(lang CXX)
Found 2 occurrence(s) in 1 file(s)
</snippet>
My test program has a single main.c file, so I would expect ${lang} to be set to "C". Here is my CMakeLists.txt file:
<code>
cmake_minimum_required(VERSION 2.6.0)
project(MyTest)
add_library(foo STATIC main.c)
</code>
Where then is ${lang} being set? Can we check either the C or the CXX form of variable for a value of "ARM"? Could the source file be in a different language (e.g., C#)? How would you like to implement the fix? |
|
|
|
(0034705)
|
|
Brad King
|
|
2013-12-04 07:59
|
|
|
Re 0013791:0034704: The ${lang} is not a widely-visible variable. It is internal to Windows-MSVC.cmake. It is the loop parameter in the WINCE block and later the argument name of the __windows_compiler_msvc macro. The latter is invoked from Windows-MSVC-(C|CXX).cmake with the corresponding language name. |
|
|
|
(0034708)
|
|
Moshe Rubin
|
|
2013-12-04 08:53
|
|
Duh <g>.
In this case we can certainly check ${MSVC_${lang}_ARCHITECTURE_ID} for "ARM". I'd like to suggest the following code (modify it any way you see fit):
<code>
if(WINCE)
. . .
else()
set(isARM "FALSE")
foreach(lang C CXX)
if(${MSVC_${lang}_ARCHITECTURE_ID} MATCHES "ARM")
set(isARM "TRUE")
break()
endif()
endforeach()
if(NOT ${isArm})
set(_PLATFORM_DEFINES "/DWIN32")
endif()
if(MSVC_VERSION GREATER 1310)
set(_RTC1 "/RTC1")
set(_FLAGS_CXX " /GR /EHsc")
if(NOT ${isArm})
set(CMAKE_C_STANDARD_LIBRARIES_INIT "kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib")
endif()
else()
set(_RTC1 "/GZ")
set(_FLAGS_CXX " /GR /GX")
if(NOT ${isArm})
set(CMAKE_C_STANDARD_LIBRARIES_INIT "kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib")
endif()
endif()
if(MSVC_VERSION LESS 1310)
set(_FLAGS_C " /Zm1000${_FLAGS_C}")
set(_FLAGS_CXX " /Zm1000${_FLAGS_CXX}")
endif()
endif()
</code>
Many thanks for holding my hand while investigating this problem <g>. It's been an honor contributing something back to the CMake project. |
|
|
|
(0034709)
|
|
Brad King
|
|
2013-12-04 09:24
|
|
Re 0013791:0034708: Thanks. Try attached "a5c3f059+0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-137.patch" which does something similar to your change. Note I also check for the THUMB and SH architectures (is that correct?).
Note that this commit:
VS: Detect MSVC compiler id on ARM toolchain
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4c04652 [^]
between 2.8.11 and 2.8.12 was likely the reason CMake started to detect the compiler id and load this file, as discussed in 0014598.
I'm not familiar with ARM development myself. I wonder why the author of that commit did not hit problems with linking of the Windows runtime libraries too. Is it only for specific platform toolsets (cmake -T option) that the Windows libraries should be excluded? Is it only for specific architectures? |
|
|
|
(0034719)
|
|
Moshe Rubin
|
2013-12-05 09:31
(edited on: 2013-12-05 09:38) |
|
Re 0013791:0034709: As far as I can ascertain, the THUMB and SHx processors are not relevant for Windows Phone, only for Windows CE.
Regarding the commit ("VS: Detect MSVC compiler id on ARM toolchain"), I checked the head version of CMakeDetermineCompilerId.cmake (http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineCompilerId.cmake;hb=HEAD [^]) but could not see the lines committed. The head version shows:
<code>
136 if("${id_platform}" STREQUAL "Itanium")
137 set(id_platform ia64)
138 endif()
</code>
The commit shows the lines (http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineCompilerId.cmake;hb=e4c046521f1da9cee44833d88320d7551719059b [^]):
<code>
129 if("${id_arch}" STREQUAL "x64")
130 set(id_machine_10 MachineX64)
131 elseif("${id_arch}" STREQUAL "Itanium")
132 set(id_machine_10 MachineIA64)
133 set(id_arch ia64)
134 elseif("${id_arch}" STREQUAL "ARM")
135 set(id_machine_10 MachineARM)
136 else()
137 set(id_machine_6 x86)
138 set(id_machine_10 MachineX86)
139 endif()
</code>
Why are they so different?
I cannot explain why the committer did not experience the problems I'm experiencing. Removing the -T platform toolset from the command line causes the build to fail. I believe that using an ARM generator implicitly implies that no Win32 system DLLs will be used at all.
|
|
|
|
(0034720)
|
|
Brad King
|
|
2013-12-05 09:48
|
|
Re 0013791:0034719: Later another commit dropped use of the target machine from compiler id detection altogether:
VS10: Do not set the TargetMachine when detecting the compiler
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=60e568cf [^]
IIUC this also would have fixed compiler id detection under ARM by itself.
If THUMB and SHx are only for WinCE then we need only to check for "ARM" as you originally suggested.
Please try "a5c3f059+0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-13791-v2.patch". |
|
|
|
(0034722)
|
|
Patrick R. Gansterer
|
|
2013-12-05 11:11
|
|
Do Windows Phone 8 support X86 architecture? If yes: How do you ensure that the system libraries do not get linked for x86 phones?
At the moment this seams to get into an direction which makes the MSVC stuff even harder to understand if we mix CPU architecture with system API. :-(
What about detecting the system API from the target platform (?) and introduce a new variable like WINRT, we can check then instead of abusing the CPU architecture for that? |
|
|
|
(0034723)
|
|
Brad King
|
|
2013-12-05 11:17
|
|
|
Re 0013791:0034722: Thanks Patrick. That makes sense to me but I'm not familiar with any embedded target platforms with MSVC tools so I'm fully dependent on contributors to work this out. What do others think? |
|
|
|
(0034725)
|
|
Patrick R. Gansterer
|
|
2013-12-05 11:23
|
|
|
Re 0013791:0034723: I'm familiar with WinCE as you might know, but haven't done anything with the other "embedded" platforms of MSVC for now. I'd like to dive into it and maybe implement it, but I'm short of time at the moment. :-( |
|
|
|
(0034828)
|
|
Brad King
|
|
2013-12-19 14:15
|
|
|
Since none of us seems to understand the relationship among WinCE, WinRT, Windows Phone 8, ARM, etc. the simplest patch to solve the immediate issue is something like "a5c3f059+0001-VS-Do-not-link-Windows-runtime-libs-for-VS-ARM-gener.patch" that just drops the system libs for the VS ARM generator. Please try it out. |
|
|
|
(0036786)
|
|
Brad King
|
|
2014-09-12 09:41
|
|
The development version of CMake now supports running with
cmake .. -G "Visual Studio 11 2012" -DCMAKE_SYSTEM_NAME=WindowsPhone -DCMAKE_SYSTEM_VERSION=8.0
or
cmake .. -G "Visual Studio 12 2013" -DCMAKE_SYSTEM_NAME=WindowsPhone -DCMAKE_SYSTEM_VERSION=8.1
to generate project files for Windows Phone. Nightly binaries are available here:
http://www.cmake.org/files/dev/?C=M;O=D [^]
If you try it, please bring feedback to the cmake-developers mailing list:
http://www.cmake.org/mailman/listinfo/cmake-developers [^]
|
|
|
|
(0038117)
|
|
Robert Maynard
|
|
2015-03-02 08:57
|
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|
a5c3f059+0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-137.patch (1,345) 2013-12-04 09:19