run-cmake: Regression: Windows is now setting `VCPKG_ROOT` to MSVC path.

Not sure if it’s related to #111 but my builds are suddenly grabbing vcpkg from visual studio.

VCPKG_ROOT: C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\vcpkg

This results in the following error when configuring

 Running command '"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\vcpkg\vcpkg.exe"' with args '^"env^",^"--bin^",^"--include^",^"--tools^",^"--python^",^"--triplet^",^"x64-windows^",^"set^"' in current directory 'C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\vcpkg'.

Note that RUNVCPKG_VCPKG_ROOT is properly set. This happens only on windows runners.

One month ago, the root was properly set

I have a somewhat atypical setup using run-cmake which configures once to then build debug and release in the same job. My first config step has the correct root but the following runs don’t.

https://github.com/openblack/openblack/blob/master/.github/workflows/ci-vcpkg.yml#L66-L95

About this issue

Original URL
State: closed
Created a year ago
Reactions: 1
Comments: 24 (9 by maintainers)

Commits related to this issue

ci: hardcode the vcpkg root Workaround for https://github.com/lukka/run-cmake/issues/113 — committed to openblack/openblack by bwrsandman a year ago

Most upvoted comments

@flichtenheld that is right, I spotted the issue and pushed again onto run-cmake@mgail, and also tested it so now it must be working. Let me know.

I assume you mean run-cmake@main. Can confirm that my build now succeeds. (e.g. https://github.com/flichtenheld/openvpn-gui/actions/runs/5278823831)

flichtenheld on Jun 16, 2023

@lukka Note that the v10 branch doesn’t seem to be updated, yet. So run-cmake@v10.6 works, but run-cmake@v10 doesn’t, yet.

flichtenheld on Jun 19, 2023

@bwrsandman @flichtenheld thank you again for helping solving this issue!

The problem is fixed in run-cmake@v10 with the release of run-cmake@v10.6.

lukka on Jun 18, 2023

Managed to get VCPKG_ROOT in CMakePresets.json working.

bwrsandman on Jun 14, 2023

Is this configuration supported? I expect the first lukka/run-cmake@main to build the packages and the next two to only build the project. Also, can configurePresetAdditionalArgs be specified only once in the configure step?

      - uses: lukka/get-cmake@latest

      - name: Restore from cache and setup vcpkg executable and data files.
        uses: lukka/run-vcpkg@v11
        with:
          vcpkgJsonGlob: 'vcpkg.json'

      - name: Run CMake+vcpkg to build packages.
        uses: lukka/run-cmake@main
        with:
          configurePreset: 'ninja-multi-vcpkg'
          configurePresetAdditionalArgs: "['-DOPENBLACK_WARNINGS_AS_ERRORS=ON']"

      - name: Run CMake+Ninja to build the code (Debug).
        uses: lukka/run-cmake@main
        with:
          configurePreset: '${{ matrix.preset }}'
          configurePresetAdditionalArgs: "['-DOPENBLACK_WARNINGS_AS_ERRORS=ON']"
          buildPreset: '${{ matrix.preset }}-debug'

      - name: Run CMake+vcpkg to build the code (Release).
        uses: lukka/run-cmake@main
        with:
          configurePreset: '${{ matrix.preset }}'
          configurePresetAdditionalArgs: "['-DOPENBLACK_WARNINGS_AS_ERRORS=ON']"
          buildPreset: '${{ matrix.preset }}-release'

@bwrsandman Sorry i missed your questions before, here below what I think are the answers.

In the first run-cmake you need to define the variable definition (as you are already doing), then that is going to be cached and it is not needed anymore in subsequent steps (this is CMake doing it). On the 2nd and 3rd run-cmake you could drop the configurePreset (and configurePresetAdditionalArgs) and just keep the build preset, it will just run the build (and skip the configuration that already happened). Let me know if it is working as I think it does 😃

lukka on Jun 14, 2023