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 <[EMAIL PROTECTED]>:
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
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
