3 ms·

> Here are some ways in which the CMake model is hamstrung... generating a build file for another build system That's the critical selling point of CMake in my

> Here are some ways in which the CMake model is hamstrung... generating a build file for another build system 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... Decoupling the build "recipe" from the build toolchain is critical for collaborative, cross-platform, cross-architecture projects, IMHO. > No way to have targets that do not generate files and have other targets depend on those targets. Isn't that exactly what an INTERFACE library is for? <https://cmake.org/cmake/help/latest/command/add_library.html#interface-libraries https://cmake.org/cmake/help/latest/command/add_library.html...>

catiopatio 4y ago
That’s just the worst of all worlds and makes for an equally terrible development experience for everyone. CLion’s native support for CMake is the only thing that makes the IDE story palatable, but everything about CMake’s architecture resists treating CMake as a declarative format and performing that kind of intelligent integration.
- dlivingston 4y ago
  First, why is it the worst of all worlds? I have a consistently good experience using CMake-generated Visual Studio projects. Second, what's the alternative? Having CMake manage the entire build, down to linkage? What benefits does that give over the current situation?
  - catiopatio 4y ago
    VS seems to be the most usable of CMake’s IDE output formats, but it still remains an awkward experience: 1) Two editable sources of truth, one of which is only sometimes overwritten when performing a target build, depending on whether the CMake inputs have changed. 2) Non-universal native IDE constructs can only be expressed if CMake supports them, and if you use IDE-specific CMake features. VS is as good as it gets, and it isn’t that great. By comparison, Xcode project support is absolutely terrible. CMake has a semi-declarative semantic representation of your project and its targets, but has to lossily translate that into a number of different, incompatible project formats, all of which are only capable of representing a different incompatible subset of CMake’s features. In several cases, CMake’s features behave differently (or not at all) depending on the generator being used. I think GP already thoroughly elucidated most of the issues with this model; all of these issues fall out of the necessarily lossy, inconsistent conversion to incompatible output formats.
Koshkin 4y ago
> I can generate a Visual Studio project Except that you don't need to, Visual Studio has support for CMake built in (since 2017).
ghoward 4y ago
> 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

catiopatio 4y ago

That’s just the worst of all worlds and makes for an equally terrible development experience for everyone. CLion’s native support for CMake is the only thing that makes the IDE story palatable, but everything about CMake’s architecture resists treating CMake as a declarative format and performing that kind of intelligent integration.

dlivingston 4y ago
First, why is it the worst of all worlds? I have a consistently good experience using CMake-generated Visual Studio projects. Second, what's the alternative? Having CMake manage the entire build, down to linkage? What benefits does that give over the current situation?
- catiopatio 4y ago
  VS seems to be the most usable of CMake’s IDE output formats, but it still remains an awkward experience: 1) Two editable sources of truth, one of which is only sometimes overwritten when performing a target build, depending on whether the CMake inputs have changed. 2) Non-universal native IDE constructs can only be expressed if CMake supports them, and if you use IDE-specific CMake features. VS is as good as it gets, and it isn’t that great. By comparison, Xcode project support is absolutely terrible. CMake has a semi-declarative semantic representation of your project and its targets, but has to lossily translate that into a number of different, incompatible project formats, all of which are only capable of representing a different incompatible subset of CMake’s features. In several cases, CMake’s features behave differently (or not at all) depending on the generator being used. I think GP already thoroughly elucidated most of the issues with this model; all of these issues fall out of the necessarily lossy, inconsistent conversion to incompatible output formats.

Koshkin 4y ago

> I can generate a Visual Studio project Except that you don't need to, Visual Studio has support for CMake built in (since 2017).

ghoward 4y ago

> 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