Consider using a CMakeSettings.json file like it is used in VS2017 instead of using our own cpfCIBuildConfigurations.json and <config>.cmake files.

[Knitschi]

VS2017 in CMake mode allows keeping multiple configurations in a CMakeSettings.json file. It more or less holds the information that we now keep in our .cmake file + cmake command line arguments.

If we could use that format we would support Visual Studio out of the box. Our .json file however also contains information about on which system the build should happen. Can this information be added to the CMakeSettings.json file without breaking it?

[Knitschi]

Currently only VS2017 supports this.

[Knitschi]

• Does the CMake mode in Visual Studio support builds vs. re-builds? It would be a problem if not. I should manually make the cmake mode work and see how visual studio behaves with this.
• We could generate the CMakeSettings.json file with the 1_Configure.py script. Can we have the file in the build-tree instead of having it parallel to the root CMakeLists.txt file?

[Knitschi]

Result

Advantages of CMake mode

• Allows building and debugging with Ninja out of Visual Studio.

Problems

• The CMakeSettings.json must be generated, because the buildRoot path must be absolute.
• The CMakeSettings.json must be located besides the CMakeLists.txt root file. Together with the above point this means that providing this file would require us to add a generated file to the source tree which is undesireable.
• Reading the cmake information in cmake server mode adds additional time to the generate step.

Other findings

• The CMakeSettings.json can contain custom variables without causing errors. However there seems to be a schema that causes the custom variables to be underlined by code analysis.
• Currently the CMakeSettings.json file is only supported by Visual Studio. Maybe we will get support for it in VS Code as well. See vector-of-bool/vscode-cmake-tools/issues/529.

Manual implementation

In order to test the cmake mode of Visual Studio I added the following CMakeSettings.json file to ACPFTestProject.

{
  "configurations": [
    {
      "name": "VS2017-shared",
      "generator": "Ninja",
      "configurationType": "Debug",
      "inheritEnvironments": [ "msvc_x64_x64" ],
      "buildRoot": "C:/dev/ACPFTestProject/Generated/Ninja",
      "installRoot": "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\install\\${name}",
      "cmakeCommandArgs": "-C\"../../Configuration/VS2017-shared.config.cmake\" --graphviz=\"CPFDependencies.dot\"",
      "buildCommandArgs": "-j 32",
      "ctestCommandArgs": "",
      "ConfigName": "Clang-shared-debug",
      "BuildSlaveLabel": "Debian-8.9-0.0.0"
    }
  ]
}

I also changed the value of the CMAKE_GENERATOR variable in the config file to Ninja.

Conclusion

Currently I don't think that the benefits are worth the required efford and ugliness of a generated file in the source tree. Currently I am happy with using the traditional solution xml files while working on windows. As it is possible to add custom variables to the CMakeSettings.json it could possibly replace the cpfCIBuildConfigurations.json file.