4 ms·
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 t
by 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 agoFirst, 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 agoVS 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.