> That's the critical selling point of CMake in my estimation. When I'm on Windows, I can generate a Visual Studio project and use its excellent debugger and co

> That's the critical selling point of CMake in my estimation. When I'm on Windows, I can generate a Visual Studio project and use its excellent debugger and code analysis tools. When I'm on Mac, I can generate an XCode project. Or a CLion project, or Makefiles, or... I've already addressed some of this in another comment ([1]), but you bring up more points, so I'll address it here. CMake's model forces it to generate build files for other build systems. The better model does not force the build system to, but it also does not preclude doing so. Separately from actually running a build (and that's important), my build system will be capable of generating files for VS, XCode, and other IDE's, but the files it generates will simply tell the IDE's how to integrate with my build system by telling them how to call it with the correct build profile. And yes, it will generate multiple possible build profiles, allowing VS users to select the solution the want to build from within VS. But this means that my build system will not only integrate better with IDE's than CMake, it will still retain full control of actual builds. This includes using debuggers and analysis tools, by the way. I wouldn't consider my work done on IDE integration until all of that is as easy as possible, and definitely as easy as CMake. > Isn't that exactly what an INTERFACE library is for? Maybe? It might be enough. At first glance (and I fully acknowledge that I could be wrong here), it seems like CMake expects the "target" to be a library of some sort. That's not the sort of thing I would personally want. I would want to be able to depend on any target for any target. But again, I could be wrong. I've never been able to understand the CMake docs. [1]: https://news.ycombinator.com/item?id=33885476 https://news.ycombinator.com/item?id=33885476