[CMake] Updated WinCE CMakefiles

[Andreas Pokorny]

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}")

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}

>
> 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.

regards
Andreas