CI Failure in conda-forge and Homebrew with CMake 3.26.0 March 2023 #1366
Comments
|
The difference between --- <unnamed>
+++ <unnamed>
@@ -52,8 +52,13 @@
endif()
-# if the installed project requested no architecture check, don't perform the check
-if("FALSE")
- return()
-endif()
-
# if the installed or the using project don't have CMAKE_SIZEOF_VOID_P set, ignore it:
-if("${CMAKE_SIZEOF_VOID_P}" STREQUAL "" OR "8" STREQUAL "")
+if(CMAKE_SIZEOF_VOID_P STREQUAL "" OR "8" STREQUAL "")
return()
endif()The problem in particular is the last diff line. Basically if a noarch C++ packages consumes a 64-bit C++ package, |
|
The regression seems to be caused by https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8133 . As this requires an upstream fix, it may take some time. Probably we can just pin CMake to <= 3.25 in conda-forge, while in homebrew we can't do that. |
|
I opened an upstream issue in CMake: https://gitlab.kitware.com/cmake/cmake/-/issues/24608 . |
traversaro
changed the title
|
CMake 3.26.1 was released yesterday with a fix for the issue I opened, so now the issue is fixed in Homebrew! In a funny (for a given definition of funny) coincidence, exactly the same data the GitHub Actions Ubuntu images have been updated to use CMake 3.26.0 (see actions/runner-images#7310), so now we have the problem in the |
|
Yes indeed. I was discussing that today w/ @Nicogene as I didn't notice this issue (the title was not mentioning Is |
|
I opened an issue upstream in actions/runner-images#7336, but I guess a few weeks may be necessary to update GitHub Actions images. The possible workaround/alternatives in the meanwhile are:
|
No, but the problem is the same on 22.04 . I was just discussing 20.04 as in the robotology-superbuild build we are using the GitHub Actions images only for 20.04, for 22.04 we are just using the Docker images. |
|
On second thought, given that the affected repos are only |
In actions/runner-images#7336 (comment) they provided a much better workaround, i.e. overwriting the existing cmake with a newer one: |
|
This should be fixed by actions/runner-images#7341 . |
The images have been updated. However, probably there is a new regression in Ubuntu 20.04 in blf due to CMake 3.26.1, that was indeed already detected in ami-iit/bipedal-locomotion-framework#635 (comment) : |
|
The problem is that someone is explicitly passing |
The version of pybind11 is passing the |
A fix/workaround for this issue is provided in ami-iit/bipedal-locomotion-framework#643 . |
|
We still have some failures in |
CMake 3.26 was recently released, and it seems there was a related regression in the configuration of
ICUBContrib:Everything was working fine with CMake 3.25.* .
The text was updated successfully, but these errors were encountered: