Sorry for length. Here's what I just experienced using one of my vendor's CMake builds: (Windows) I open a console, make a build directory, and run cmake.exe,

Sorry for length. Here's what I just experienced using one of my vendor's CMake builds: (Windows) I open a console, make a build directory, and run cmake.exe, which generates MSVC project files. I open these in Visual Studio and already realize there's going to be a problem because the target is "Debug x86" even though I passed -DCMAKE_BUILD_TYPE=Release and this would be cross-compiled for Arm Cortex-M. (The vendor should have this in their CMakeLists.txt, so either they had a large misstep during an easy CMake step, CMake is not intuitive enough for use by a large semiconductor firm, or CMake failed to inform MSVC that the target is ARM.) For shits and gigs, I press build. At least a dozen times: Unknown compiler. (I have two different Arm toolchains... one contained in PATH, the other in a standard install directory.) Now... into Configuration Manager, I change the platform to ARM, but the new error is "cannot open include file". Thanks, CMake... At this point, I can go into Project Properties, manually add the include directory, and proceed with trying to build. Last time I did this, there were more errors and missing files. At some point, it's easier to just put all of the files in a single directory, create an .o out of anything that looks compilable, link it against anything that looks like a linker script, and try to compile a binary with all those objects and scripts. ----- (WSL) (The Arm toolchain is installed via package manager and is in my path.) Running cmake .. -DCMAKE_BUILD_TYPE=Release (it really is a pain typing that with the shift key held, and it's too short for Caps Lock plus I've mapped Caps Lock to a bunch of AHK macros): -Found assembler: /usr/bin/cc Alright. Already, this is problematic. For completeness: "make" results in #warning Unsupported Architecture. At this point, I need to know enough about CMake to "create a toolchain file", according to StackOverflow. So I've done this---manually specifying arm-none-eabi-gcc as my compiler plus a few other possibly correct flags---but honestly, I have no idea, because CMake probably has more possible non-custom flags than mpv! rm -rf build && mkdir build && build cmake ... -DCMAKE_TOOLCHAIN_FILE:PATH=... The correct compiler is detected, but I'm still getting "Unsupported Architecture". Wat? ----- I can run ccmake to try to fish out all the possible settings. When I change each of the tools to arm-none-eabi-*, I can't successfully configure (to exit ccmake) because of an error: The C compiler "/usr/bin/arm-none-eabi-gcc" is not able to compile a simple test program. ...and eventually, undefined reference to _exit So, I can probably get this to keep going by passing -k to gmake, but in ccmake (which oddly only sometimes will reset only a few of the previously changed settings, such as CMAKE_VERBOSE_MAKEFILE) I do not find the argument for passing a flag to make, so this is a dead end. ----- Alternatively, I can dive into the manufacturer's CMakeLists.txt, but it's a rabbit hole. The base-level file is short: cmake_min... include(Config.cmake) enable_language(C ASM) project(...) include(${CMAKE_CURRENT_LIST_DIR}/cmake/generated_src.cmake) Config.cmake has one line: the path of the toolchain. I try /usr/bin and repeat. At this point, I wonder if every CMake expert has also deleted and recreated "build" three times by now. (Spoiler: this didn't change anything.) Along the other road, the cmake directory contains three cmake files. In one file, arm-none-eabi-gcc is hardcoded as the compiler (along with friends: ranlib, ar, objdump, etc), so the possibility of using armcc seems slim. In the second file, I see the flags that should stop all of the errors, such as -mcpu=cortex-m33 and the CMSIS include path and everything else. However, this isn't a standard variable name but something like MFRTOOL_CMAKE_CXX_FLAGS. The manufacturer's (Windows-based) tool might clear all this up. Maybe not. But... Everything already exists in plaintext in the project directory to compile, if CMake could put the pieces together. Anyway, why use a CMakeLists.txt at all if you need an external tool? Why not have a better error message if a tool is required? (The answer, of course, is that CMake requires more than cursory learning and---as with any unintuitive language---most users don't want to learn more than necessary or more than StackOverflowable. Plus, I can imagine the original CMakeLists.txt developer for this BSP doesn't have the resources to dump into getting this working with every Arm compiler on every host OS for every board in their repertoire.) The final cmake file includes all source using GLOB_RECURSE. This tells me that my earlier intuition of moving all source into one directory and compiling "the old way" (a 20-line Makefile) would probably be the least stress and least rabbit holes. ----- In the end, I don't know if I should blame the vendor, blame CMake, or blame myself and lack of tool knowledge. I DO know that I can throw together a Makefile in under 30 minutes and it will definitely take more than 30 minutes to get CMake to compile in either Windows or Linux. ----- If I tell a person, "use the tools around my house plus this book to make an acoustic guitar" and they throw out the book and go straight to the metalworking tools to shape the body, I'd have serious doubts about their ability as a maker. This theoretical person is how I feel about CMake. I have to explicitly (in a very verbose, clunky, uppercase flag format) tell CMake how to use my (very standard) tools to compile an essentially "hello world" CMSIS package. The author is right. It sucks.