In CMake 3.3, a commit made it so that the find_package module in CMake had a compatibility mode where it would automatically search for packages in a /lib subdirectory. In CMake 3.6, this compatibility mode was reverted for all platforms except Windows.
That means that since CMake 3.3, we haven't actually been using the path as specified in curl_DIR, but we have instead been inadvertently relying on that fallback behavior.
In CMake 3.28, that compatibilty mode was also removed for Windows, meaning that we are now failing to find_package(curl) in downstream packages (like resource_retriever).
Fix this by adding in the "lib" directory that always should have been there. I'll note that this only affects our Windows builds, because this code is in a if(WIN32) block.
I'll note that this one is kind of hard to test; just running CI on this won't show us succeeding before and after. I will say that in local testing, where I've upgraded my CMake to 3.29.2 on Windows, this fixes the issue for me. And of course I'll run CI on it just to make sure there are no ill effects on earlier CMake versions.
This is an automatic backport of pull request #96 done by Mergify.
clalancette
commented
4 months ago
In CMake 3.3, a commit made it so that the find_package module in CMake had a compatibility mode where it would automatically search for packages in a/lib subdirectory. In CMake 3.6, this compatibility mode was reverted for all platforms except Windows.
That means that since CMake 3.3, we haven't actually been using the path as specified in
curl_DIR, but we have instead been inadvertently relying on that fallback behavior.In CMake 3.28, that compatibilty mode was also removed for Windows, meaning that we are now failing to find_package(curl) in downstream packages (like resource_retriever).
Fix this by adding in the "lib" directory that always should have been there. I'll note that this only affects our Windows builds, because this code is in a if(WIN32) block.
The commit to CMake that caused this is https://github.com/Kitware/CMake/commit/0a81110b842fd7b00cdacc55c270458ddaa2eb73
I'll note that this one is kind of hard to test; just running CI on this won't show us succeeding before and after. I will say that in local testing, where I've upgraded my CMake to 3.29.2 on Windows, this fixes the issue for me. And of course I'll run CI on it just to make sure there are no ill effects on earlier CMake versions.
This is an automatic backport of pull request #96 done by Mergify.