Add support for cmake/ninja --install

[crud89]

Hi,

I am currently using the action to build my project and everything works fine. However, my project does not only contain source files that need to be build, but rather uses install to put everything in place (e.g. raw files, artifacts, headers, etc.). It would be quite convenient, if run-cmake could be configured to automatically run ninja install or cmake --install after a successful build. For ninja, the install directory is stored in the CMakeSettings.json file. The action could treat it just as it does with the buildRoot directory (i.e. ignore and set to a default; maybe make it configurable).

Do you think this is possible?

Thanks and regards, Carsten.

[lukka]

@Aschratt yes, it make sense to add a option similar to buildWithCMake, called installWithCMake, with default set to false. For the time being, the solution is to run cmake --install in a run step, assuming the cwd is the right one e.g.:

- name: Install with CMake
    run: cmake --install

[russkel]

Came across this as well. Would be a nice to have.

[garyttierney]

FWIW, you can accomplish this using the run-cmake action by specifying the build target:

    - name: 'Build with CMake'
      uses: lukka/run-cmake@v3
      with:
        cmakeListsTxtPath: '${{ github.workspace }}/CMakeLists.txt'
        buildWithCMakeArgs: '--target install'

[lukka]

@garyttierney yes, thanks for the good point! I think that should be documented.

[WorkingRobot]

FWIW, you can accomplish this using the run-cmake action by specifying the build target:

    - name: 'Build with CMake'
      uses: lukka/run-cmake@v3
      with:
        cmakeListsTxtPath: '${{ github.workspace }}/CMakeLists.txt'
        buildWithCMakeArgs: '--target install'

This is a good workaround, but it doesn't work when you have CMakeSettings. Instead, I had to add install as an argument to the end of buildCommandArgs. Either way, it would still be nice to have support for this built into the action in some way.

[lukka]

Closing as a very old ticket. Please take a look to run-cmake@v10 and see if CMakePreset.json suites your needs.

[crud89]

@lukka I know I am a little bit late, but I recently updated my build to take advantage of presets and by doing so I also updated to v10, so I thought I keep you updated. It seems that, at least for version 3.20 there is an issue with cmake, that prevents the following example preset to be properly processed:

{
  "version": 2,
  "cmakeMinimumRequired": {
    "major": 3,
    "minor": 20,
    "patch": 0
  },
  "configurePresets": [
    {
      "name": "windows-x64",
      "hidden": true,
      "generator": "Ninja",
      "binaryDir": "${sourceDir}/out/build/${presetName}",
      "architecture": {
        "value": "x64",
        "strategy": "external"
      }
      "cacheVariables": {
        "CMAKE_INSTALL_PREFIX": "${sourceDir}/out/install/${presetName}"
      },
      "vendor": {
        "microsoft.com/VisualStudioSettings/CMake/1.0": {
          "hostOS": [ "Windows" ]
        }
      }
    }
  ],
  "buildPresets": [
    {
      "name": "install-windows-x64",
      "configurePreset": "windows-x64",
      "configuration": "Release",
      "targets": "install"
    }
  ]
}

It appears that - even though documented, the mere existence of the targets field within the build preset prevents the presets file from being parsed:

CMake Error: Could not read presets from ...: Invalid preset

This is fixed at least in cmake 3.23 (or at least I am unable to reproduce it there), so when using lukka/get-cmake@latest the approach should work. However, since Visual Studio 2019 does only ship with cmake 3.20 and this issue preventing the usage of such presets on the client side entirely, this might not be an option.

So yes - the issue is kinda fixed and obsolete now. At least when using VS 2022 or building entirely from command line with newer releases than CMake 3.23, there should not be any issue. However, since I want to still support VS 2019 and CMake 3.20, I keep using an extra build step (and having no build presets):

- name: Install with CMake
  run: |
    Set-Location '${{ steps.setup-environment.outputs.buildPath }}/${{ matrix.configuration }}'
    cmake --install .

[lukka]

@crud89 thanks for the info. If there is anything it should be done on run-cmake's side, I apologies for not having grasped it, but please let me know.

Also, note that get-cmake is not yet fetching 3.23, latest corresponds to 3.22.2. If this is unexpected, you can open an issue on the get-cmake repository.

Regarding VS, it should be possible to leverage with VS an external CMake installation (as it was with CMakeSettings.json), which would get past problems like this where the VS bundle CMake is not good enough. If this is not possible with CMakePresets.json, I'd suggest to request it as a feature.

[crud89]

Thanks for the reply! Sorry, if this was not so clear, but there's nothing that needs to be changed in run-cmake. I just wanted to make sure that this issue is documented. This is simply due to the fact that VS 2019 will only ever ship with CMake 3.20, which has this issue.

So I could go two ways here: document it, so users use an external CMake version instead, or keep the previous solution using the extra build step until I want to drop VS 2019 support. I opted for the latter.

Thanks again! 🙂

[lukka]

@crud89 thanks, the interesting part I'd like to know more is whether the CMake fetched withget-cmake does get priority over the CMake bundled within VS2019. If this is not happening, I wonder whether there is something run-cmake can do. Do you have a sample workflow that reproduces the problem and that I could take a look at?

[crud89]

It does. I haven't tested what happens if one uses the developer shell (e.g. using this action), but when using get-cmake it uses the external version.

You can find my project repo here. The release workflow uses CMake install. However the workflow works, it's just that the VS 2019 client-side does not work, if I use the preset from above and remove the extra install step. Again, I don't think that there's anything for you to do here, this is a issue on the CMake side, that has been patched. But the patched version will never be available in VS 2019. 🙂