2×1=10

While CLion may become a good IDE for embedded development, it really struggles with non conformant build scenarios at the time being. As far as building on Windows is concerned, you may either chose a MinGW- or cygwin-based toolchain and that’s it.

CMake, however, being the underlying build system, supports the notion of externally defined toolchains (-D CMAKE_TOOLCHAIN_FILE=...), which may be used to trick CLion into cross-compiling when it really doesn’t want to.

Note that this is merely a hack to get you starting and by no means a full-fledged solution. (Side note: Please share your insights.)

As for my system, I finally went with MinGW (mingw-base 2013072200) as this solution handles paths Windows-like, i.e. without cygwin’s /cygdrive/ mangling; I also installed arm-none-eabi-gcc 4.9.2. Note also that installing the arm-gcc toolchain within cygwin might be an easier solution in the long run.

First, we create a toolchain – in this case for a Cortex-M0+ – like follows:

include(CMakeForceCompiler)
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR cortex-m0plus)

find_program(ARM_CC arm-eabi-gcc
    ${TOOLCHAIN_DIR}/bin
    )
find_program(ARM_CXX arm-eabi-g++
    ${TOOLCHAIN_DIR}/bin
    )
find_program(ARM_OBJCOPY arm-eabi-objcopy
    ${TOOLCHAIN_DIR}/bin
    )
find_program(ARM_SIZE_TOOL arm-eabi-size
    ${TOOLCHAIN_DIR}/bin)

CMAKE_FORCE_C_COMPILER(${ARM_CC} GNU)
CMAKE_FORCE_CXX_COMPILER(${ARM_CXX} GNU)

set(CMAKE_C_FLAGS
  "${CMAKE_C_FLAGS}"
  "-fno-common -ffunction-sections -fdata-sections"
)

if (CMAKE_SYSTEM_PROCESSOR STREQUAL "cortex-m0plus")

  set(CMAKE_C_FLAGS
    "${CMAKE_C_FLAGS}"
    "-mcpu=cortex-m0plus -mthumb"
  )

else ()
  message(WARNING
    "Processor not recognised in toolchain file, "
    "compiler flags not configured."
  )
endif ()

# fix long strings (CMake appends semicolons)
string(REGEX REPLACE ";" " " CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")

set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS}" CACHE STRING "")

set(BUILD_SHARED_LIBS OFF)

In CLion’s Build, Execution, Deployment > CMake settings we then set the CMake Generation options with

-DTOOLCHAIN_DIR:PATH=c:/path/to/arm-eabi/ 
-DCMAKE_TOOLCHAIN_FILE=toolchain-gcc-arm-eabi.cmake

as can be seen in the following image.

If we weren’t using MinGW but cygwin, CMake would be unable to find the executables given a MinGW-style path (e.g. c:/some/thing); a cygwin-style path (e.g. /cygdrive/c/some/thing) would then have to be used here. However, when the cygwin toolchain is selected in CLion, all source file paths are also presented cygwin-style, which obviously can’t be accessed from a non-cygwin application. Long story short: Know your tools, I didn’t.

Using Help > Show Generated CMake Files in Explorer you can see the generated project files.

Deleting this folder forces a full invalidation of CMake’s generated cache, which might otherwise not happen.

Afterwards you can trigger a regeneration of the cache by using the Reload CMake Project button in the CMake Problem pane.

Now the CMake Cache should show the correct paths.

If you then build your project, CMake will use the crosscompiler and place the binaries in the folder you deleted earlier.