[CMake] Problem with cygwin and CodeSourcery's ARM Toolchain

[Thomas Kindler]

Hi!

I'm just playing around with cmake for a new embedded project using a 
STM32 ARM Cortex-M3 processor.

I have installed cmake 2.6.0-patch 2 from the cygwin distribution and 
use a windows gcc toolchain from www.codesourcery.com.

After reading the manual and FAQ, i created a CodeSourcery.cmake file:

   # the name of the target operating system
   #
   set(CMAKE_SYSTEM_NAME      Generic)
   set(CMAKE_SYSTEM_VERSION   1)
   set(CMAKE_SYSTEM_PROCESSOR arm-eabi)

   # which compilers to use for C and C++
   #
   set(CMAKE_C_COMPILER       arm-none-eabi-gcc)
   set(CMAKE_CXX_COMPILER     arm-none-eabi-g++)

   # adjust the default behaviour of the FIND_XXX() commands:
   # search headers and libraries in the target environment,
   # search programs in the host environment
   #
   set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
   set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
   set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)


and a CMakeLists.txt in my project directory:

   project(STM32 C)
   cmake_minimum_required(VERSION 2.6)

   set(CMAKE_TOOLCHAIN_FILE  CodeSourcery.cmake)

   set(COMPILE_DEFINITIONS_DEBUG    -O0 -g3 -DDEBUG)
   set(COMPILE_DEFINITIONS_RELEASE  -O2)

   add_definitions(
     -Wall
     -Wshadow
     -Wcast-qual
     -Wwrite-strings
     -Winline

     -std=gnu99

     -DSTM32F10X_HD           # for peripheral library
     -DUSE_STDPERIPH_DRIVER
     -DGCC_ARMCM3             # for FreeRTOS
   )

   include_directories(
     ${STM32_SOURCE_DIR}/.
     ${STM32_SOURCE_DIR}/fwlib
     ${STM32_SOURCE_DIR}/fwlib/inc
     ${STM32_SOURCE_DIR}/FreeRTOS/Source/include
   )

   link_directories(
     ${STM32_BINARY_DIR}/fwlib
   )

   add_executable(stm32test
     bigfont.c
     bitmap.c
     enc28j60.c
     graphics.c
     lcd7565.c
     main.c
     syscalls.c
     sysfont.c
     systick.c
     uart.c
   )

   target_link_libraries(stm32test libstm32fw.a)

...


The problem is:  It doesn't work:

$ cmake -DCMAKE_TOOLCHAIN_FILE=CodeSourcery.cmake .
-- The C compiler identification is GNU
-- Check for working C compiler: 
/cygdrive/c/code/sourcery/bin/arm-none-eabi-gcc.exe
-- Check for working C compiler: 
/cygdrive/c/code/sourcery/bin/arm-none-eabi-gcc.exe -- broken
CMake Error at 
/usr/share/cmake-2.6.2/Modules/CMakeTestCCompiler.cmake:32 (MESSAGE):
   The C compiler "/cygdrive/c/code/sourcery/bin/arm-none-eabi-gcc.exe" 
is not
   able to compile a simple test program.

   It fails with the following output:

    Change Dir: /home/tkindler/multiturn-stm32/CMakeFiles/CMakeTmp

   Run Build Command:/usr/bin/make.exe "cmTryCompileExec/fast"

   /usr/bin/make -f CMakeFiles/cmTryCompileExec.dir/build.make
   CMakeFiles/cmTryCompileExec.dir/build

   make[1]: Entering directory
   `/home/tkindler/multiturn-stm32/CMakeFiles/CMakeTmp'

   /usr/bin/cmake.exe -E cmake_progress_report
   /home/tkindler/multiturn-stm32/CMakeFiles/CMakeTmp/CMakeFiles 1

   Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.obj

   /cygdrive/c/code/sourcery/bin/arm-none-eabi-gcc.exe -o
   CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.obj -c
   /home/tkindler/multiturn-stm32/CMakeFiles/CMakeTmp/testCCompiler.c

   make[1]: Leaving directory
   `/home/tkindler/multiturn-stm32/CMakeFiles/CMakeTmp'

   arm-none-eabi-gcc.exe:
   /home/tkindler/multiturn-stm32/CMakeFiles/CMakeTmp/testCCompiler.c: 
No such
   file or directory

   arm-none-eabi-gcc.exe: no input files

   make[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.obj] 
Error 1

   make: *** [cmTryCompileExec/fast] Error 2


   CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
   CMakeLists.txt:8 (project)


-- Configuring incomplete, errors occurred!


cmake tries to use cygwin-style absolute "/home/tkindler.." paths, which 
arm-none-eabi-gcc doesn't seem to like (being a native win32 program).

My old makefile used relative paths to invoke the compiler. How can I do 
this in cmake generated makefiles?!

Prepending "c:/cygwin/" to all paths should also solve the problem.


greetings,
-- 
Thomas Kindler <mail+cmake at t-kindler.de>