Home > front end >  Unexpected Behavior for CMake Policy CMP0074 on Github Actions
Unexpected Behavior for CMake Policy CMP0074 on Github Actions

Time:01-27

My CMake build on Github Actions can't find Boost. So I enable policy CMP0074 and set variable Boost_ROOT. After that CMake finds Boost, but emits this warning:

CMake Warning (dev) at myproject/CMakeLists.txt:14 (find_package):  
  Policy CMP0074 is not set: find_package uses <PackageName>_ROOT
  variables.   Run "cmake --help-policy CMP0074" for policy details. 
  Use the cmake_policy command to set the policy and suppress this
  warning.

  Environment variable Boost_ROOT is set to:

      C:\local\boost

  For compatibility, CMake is ignoring the variable.

So that seems contradictory to me. Without CMP0074 it does not work. With CMP0074 it works but complains.

Details

I am trying to get a build running on Github Actions using the "windows-2022" platform which includes cmake version 3.25.1.

I have one step to install boost and another to build my code. On my first attempt, the build of my code failed because it could not find boost. So I made two changes:

  • I edited my CMakeLists.txt file and added this line:

    cmake_policy(SET CMP0074 NEW)

  • I set environment variable Boost_ROOT equal to C:\local\boost (the path to which I install boost on the server).

Now, my build finds the boost header files and progresses further. (It fails at the linking stage because it can't find the boost lib files and I am working on that). But the build emits the warning mentioned above. This seems contradictory to me:

  • Without CMP0074/Boost_ROOT, it does not find the Boost header files
  • With CMP0074/Boost_ROOT, it finds the Boost header files, while also emitting a warning to say that Boost_ROOT is ignored

This makes no sense to me and I am unable to recreate the problem locally (I am running cmake version 3.25.1, same as the windows-2022 container on Github Actions.) Any idea what I'm doing wrong?

This is how my yaml file looks like so far:

name: Test
on: workflow_dispatch
jobs:
  job1:
    runs-on: windows-2022
    steps:
    - uses: actions/checkout@v3
    - name: Setup MSBuild
      uses: microsoft/[email protected]
    - name: Setup Boost
      run: |
        $Url = "https://boostorg.jfrog.io/artifactory/main/release/1.81.0/binaries/boost_1_81_0-msvc-14.2-64.exe"
        (New-Object System.Net.WebClient).DownloadFile($Url, "$env:TEMP\boost.exe")
        Start-Process -Wait -FilePath "$env:TEMP\boost.exe" "/SILENT","/SP-","/SUPPRESSMSGBOXES","/DIR=C:\local\boost"
    - name: Build Myproject
      env:
        Boost_ROOT: C:\local\boost
      run: |
        Expand-Archive -Path Myproject.zip -DestinationPath C:\local
        cd C:\local\Myproject
        mkdir build
        cd build
        cmake  -G "Visual Studio 17 2022" -A x64 ..
        cmake --build . --config Release

CodePudding user response:

With CMP0074/Boost_ROOT, it finds the Boost header files, while also emitting a warning to say that Boost_ROOT is ignored.

Actually, there is no contradiction in such behavior, because Boost headers are found via ... BOOST_ROOT variable (case insensitive!).

Details:

  1. When a project specifies (with cmake_minimum_required) that it is written for CMake 3.11 (or older), CMake doesn't set policy CMP0074.
  2. When such project calls find_package(Boost) and CMake observes, that environment variable Boost_ROOT is set, it emits the warning and does not add this variable implicitly to find_path and find_library calls, performed by module FindBoost.cmake.
  3. However, the module FindBoost.cmake explicitly adds environment variable BOOST_ROOT to its find_path and find_library calls, so the directory specified by the variable is actually searched.
  4. On Windows environment variables are case-insensitive. (Unlike to Linux variables, unlike to CMake variables). So Boost_ROOT and BOOST_ROOT are actually refer to the same variable.

There is some specific about FindBoost.cmake module: it supports (and documents!) using BOOST_ROOT environment variable as a hint for search. Such decision could look strange assuming CMake automatically adds Boost_ROOT variable to the search paths. But FindBoost.cmake has been written long before CMake 3.12 (see e.g. FindBoost documentation for CMake 3.1), so Boost developers couldn't be aware that CMake will introduce such feature at the system level.


That is, you could ignore such warning. The warning will disappear when the project migrates to CMake 3.12 or newer (as a minimum requirement).

Alternatively, instead of Boost_ROOT you could set BOOSTROOT environment variable as a hint: such variable is not checked by CMake itself, but used in FindBoost.cmake module.

  • Related