Hacker News Reader

Comment by fetbaffe | Hacker News Reader

I recently experimented with C++17/20 in CLion & CMake. I tried to organize my project that different namespaced folders could have their own cmake-file and depend on different external libraries (dlls).

I gave up. CMake is just too frustrating to work with. Hard to debug, different API versions, many different ways to do the same thing, hard to understand the abstraction of CMake itself. Total time sink. I will never use that again.

View on HN

Totally understand you. I once tried to use CMake by creating a hierarchy of a bunch of git submodules for my dependencies with their own CMakeLists.txt, and it failed epically. One of the main problems arose when two different submodules depended on different versions of another submodule, which really confused the hell out of CMake.

For me the biggest hurdle is the disconnect between the way CMake and Visual Studio see the world. I still use it but I have my own batch files for preparing the environment, installing the dependencies, and building the CMake files in a directory outside my source tree.

CMake you run to generate files that will build your thing in a single configuration (platform, runtime settings, etc).

Visual Studio wants to have a solution where you can switch between many configurations (platforms, runtime etc).

Yes, I have looked into latest Visual Studio CMake integration but it doesn't suit my needs because it puts the build files in some arbitrary hidden random location on disk.

I've got a CMake project that builds multiple libraries that depend on different libraries.

If I remember correctly I never figured out how to get the target in a subfolder, you need the target to your dependencies.

I don't understand. To do that you just need to pass the subdir with your CMakeLists.txt to add_subdirectory(). Exactly which problems did you experienced?

Looking at it now, I wanted to copy files into the build folder after build step was done with add_custom_command() with copy_if_different and with target TARGET <project> POST_BUILD, but when I would put that in a subdirectory it wouldn't work because there was no target.

   add_custom_command(TARGET project POST_BUILD
        COMMAND ${CMAKE_COMMAND} -E copy_if_different
        some.dll
        $<TARGET_FILE_DIR:project>)

> I recently experimented with C++17/20 in CLion & CMake. I tried to organize my project that different namespaced folders could have their own cmake-file and depend on different external libraries (dlls).

What's hard about that? You have a subproject per folder, in each subproject you specify the build targets and dependencies, and then you just specify build precedence in downstream libraries when need.

Exactly which problems did you experienced getting this to work?

> many different ways to do the same thing

This is a huge problem with too many things - CMake included. Backwards compatibility is often being praised too highly.

Reply on news.ycombinator.com