2x1=10

While CLion may become a good IDE for embed­ded devel­op­ment, it real­ly strug­gles with non con­for­mant build sce­nar­ios at the time being. As far as build­ing on Win­dows is con­cerned, you may either chose a MinGW- or cyg­win-based tool­chain and that’s it.

CMake, how­ev­er, being the under­ly­ing build sys­tem, sup­ports the notion of exter­nal­ly defined tool­chains (-D CMAKE_TOOLCHAIN_FILE=...), which may be used to trick CLion into cross-com­pil­ing when it real­ly doesn’t want to.

Note that this is mere­ly a hack to get you start­ing and by no means a full-fledged solu­tion. (Side note: Please share your insights.)

As for my sys­tem, I final­ly went with MinGW (mingw-base 2013072200) as this solu­tion han­dles paths Win­dows-like, i.e. with­out cygwin’s /cygdrive/ man­gling; I also installed arm-none-eabi-gcc 4.9.2. Note also that installing the arm-gcc tool­chain with­in cyg­win might be an eas­i­er solu­tion in the long run.

First, we cre­ate a tool­chain — in this case for a Cor­tex-M0+ — like fol­lows:

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 set­tings we then set the CMake Gen­er­a­tion options with

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

as can be seen in the fol­low­ing image.

If we weren’t using MinGW but cyg­win, CMake would be unable to find the exe­cuta­bles giv­en a MinGW-style path (e.g. c:/some/thing); a cyg­win-style path (e.g. /cygdrive/c/some/thing) would then have to be used here. How­ev­er, when the cyg­win tool­chain is select­ed in CLion, all source file paths are also pre­sent­ed cyg­win-style, which obvi­ous­ly can’t be accessed from a non-cyg­win appli­ca­tion. Long sto­ry short: Know your tools, I didn’t.

Using Help > Show Generated CMake Files in Explorer you can see the gen­er­at­ed project files.

Delet­ing this fold­er forces a full inval­i­da­tion of CMake’s gen­er­at­ed cache, which might oth­er­wise not hap­pen.

After­wards you can trig­ger a regen­er­a­tion of the cache by using the Reload CMake Project but­ton in the CMake Prob­lem pane.

Now the CMake Cache should show the cor­rect paths.

If you then build your project, CMake will use the cross­com­pil­er and place the bina­ries in the fold­er you delet­ed ear­li­er.