[CMake] Updated WinCE CMakefiles

[Clemens Arth]

Hi,

Andreas Pokorny schrieb:
> Hello Clemens,
>
> I still try to get some time slot to try your patches here. Since we
> do not have that many 2005
> licenses, I cannot do that as a kind of submarine project :).
>
> 2008/9/30 Clemens Arth <clemens.arth at gmx.at>:
>   
>> Andreas,
>>
>> I had a look at your modified files and, like the old ones, they seem to
>> work quite well. However, there are some things that are somehow unclear to
>> me or cause problems here:
>>
>> First, in WinCE.cmake, you replace the decimal string of the system version
>> CMAKE_SYSTEM_VERSION, which does not work in my case. Although WM5 is
>> considered as 5.1 and WM6 as 5.2, this causes a version of 0x51 and 0x52
>> respectively, which should be 0x501 and 0x502, otherwise compilation fails
>> with some error like "versions of Windows CE < 3.0 are not supported".
>> Changing your syntax to
>>
>> STRING(REGEX REPLACE "([0-9]*)\\.([0-9]*)" "0x\\10\\2"
>> CMAKE_SYSTEM_VERSION_HEX "${CMAKE_SYSTEM_VERSION}")
>>     
>
>   
Maybe we can skip that at least for the Visual Studio stuff. I don't 
know if CEVER can be accessed somewhere outside of Visual Studio, but I 
can also write something like $(CEVER) in -D_WIN32_WCE=$(CEVER) and the 
visual studio compiler fills it up automatically.

> Oh yes thats one of the uglier problems. I guess we need to do something like
>
> STRING(REGEX MATCH "([0-9]*)\\.([0-9]*)" matched_CMAKE_SYSTEM_VERSION
> "${CMAKE_SYSTEM_VERSION}")
> STRING(LENGTH CMAKE_MATCH_1 CMAKE_MATCH_1_LENGTH) # or MATCH_2 ?
> IF(CMAKE_MATCH_1_LENGTH GREATER 1)
>     SET(CMAKE_SYSTEM_VERSION_HEX "0x${CMAKE_MATCH_0}${CMAKE_MATCH_1}")
> ELSE(CMAKE_MATCH_1_LENGTH GREATER 1)
>     SET(CMAKE_SYSTEM_VERSION_HEX "0x${CMAKE_MATCH_0}0${CMAKE_MATCH_1}")
> ENDIF(CMAKE_MATCH_1_LENGTH GREATER 1)
>
>   
>> fixes this in my case. I now wrote some generator for Visual Studio which
>> only takes a cached CMAKE_SYSTEM_NAME variable and, thus selects the right
>> toolchain. I further modified your WinCE.cmake(-cl) configuration to
>> WM5.cmake(-cl) to contain additional flags needed. Also a cached variable
>> PLATFORM_SDKS is used that selects only those platforms from the set of all
>> platforms installed. This works pretty well, as one simply has to create
>> this cache file first, and the rest works as expected. I still have to
>> modify the original files in the modules directory responsible for the test
>> build, because the test compile uses the right compiler in
>> VDSIR/VC/ce/bin/x86_arm, but cannot link the test program due to a missing
>> entry point.
>>     
>
> And the linker flag /ENTRY:mainACRTStartup does not help here? If not we will
> have to modify the test code in share/cmake-x/Modules/*.{in,c,cxx,cpp}
>
>   
Unfortunately not, but if I update the CMakeTestCCompiler.cmake and 
CMakeTestCXXCompiler.cmake files to contain a function called 
mainCRTStartup doing the same thing as the original main function it 
works. To remove the ABI Compiler check errors that follow without any 
harm, I also have to alter the CMakeCCompilerABI.c and 
CMakeCXXCompilerABI.cpp files to also contain a function called 
mainCRTStartup doing the same as the already defined main function.
>> I tried using your WinCE file for generating NMake Makefiles without caching
>> anything and by typing
>>
>> "cmake.exe -G"NMake Makefiles" -DCMAKE_SYSTEM_NAME=WINCE"
>>
>>     
>
> If you do not set the compiler to the arm cl.exe you will always
> create x86 binaries,
> and since you set WinCE it will try to link to libs that only exist for WinCE.
> So you need:
> "cmake.exe -G"NMake Makefiles" -DCMAKE_SYSTEM_NAME=WINCE" \
>         -DCMAKE_CXX_COMPILER=${VSDIR}/VC/ce/x86_arm/cl.exe" \
>         -DCMAKE_C_COMPILER=${VSDIR}/VC/ce/x86_arm/cl.exe"
> or something similar
>
>   
>> This fails here because it tries to link the coredll.lib trying to compile
>> the simple test program. I'm not sure if this is the error you mentioned,
>> because whatever I try to test-compile it tells me that he uses the cl.exe
>> located in VSDIR/VC/bin, which is not an embedded compiler anyway. However,
>> I'm sure that internally it uses the right compiler to compile the program,
>> and the information message about what cl is used is simply wrong. How do
>> you get your project configured for Makefiles?
>>     
>
> We have a toolchain file here that sets these variables, but the
> toolchain file relies
> on environment variables to be set. We have one that tells us the path
> to the visual
> studio install. Another one that tells us the SDK path. And finally we have to
> mention respective SDK subdirectories inside INCLUDE and LIBS. Otherwise
> TRY_COMPILE checks would fail, because for some reason it ignores LINK_LIBRARIES
> and other cmake flags. At least we had problems with that recently. I wanted to
> invest more time on that issue, but I did not find the time slot yet.
>
>   
Now I've set the compilers manually and it sets the CL platform to THUMB 
automatically. Then it raises the /RTC1 warning and finally fails in 
opening the coredll.lib. When using the VS generator the correct libs 
are found because the new generator with SDK support always uses the 
first SDK found on the computer to compile the test program - thus 
somehow internally the right libs are found. As a negative consequence 
the problem of the missing mainCRTStartup entry point rises which can 
only be tackled inserting the additional function definitions.

Concerning time slots we are all having the same problems. As soon as 
you start with working on one issue you find the slot just to be narrow 
enough to find another problem that also has to be fixed later....

Regards
Clemens