Add "lib" to the Windows curl search path. #96
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 <prefix>/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. Signed-off-by: Chris Lalancette <clalancette@gmail.com>
|
By the way: huge thanks to @azeey for realizing what the actual problem here is; I'm just making the pull requests. |
wjwwood
approved these changes
May 2, 2024
|
CI:
|
azeey
approved these changes
May 2, 2024
|
@Mergifyio backport jazzy iron humble |
✅ Backports have been created
|
mergify bot
pushed a commit
that referenced
this pull request
May 3, 2024
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 <prefix>/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. Signed-off-by: Chris Lalancette <clalancette@gmail.com> (cherry picked from commit 1839d58)
Closed
mergify bot
pushed a commit
that referenced
this pull request
May 3, 2024
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 <prefix>/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. Signed-off-by: Chris Lalancette <clalancette@gmail.com> (cherry picked from commit 1839d58)
mergify bot
pushed a commit
that referenced
this pull request
May 3, 2024
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 <prefix>/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. Signed-off-by: Chris Lalancette <clalancette@gmail.com> (cherry picked from commit 1839d58)
This was referenced May 3, 2024
clalancette
added a commit
that referenced
this pull request
May 6, 2024
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 <prefix>/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. Signed-off-by: Chris Lalancette <clalancette@gmail.com> (cherry picked from commit 1839d58) Co-authored-by: Chris Lalancette <clalancette@gmail.com>
clalancette
added a commit
that referenced
this pull request
May 6, 2024
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 <prefix>/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. Signed-off-by: Chris Lalancette <clalancette@gmail.com> (cherry picked from commit 1839d58) Co-authored-by: Chris Lalancette <clalancette@gmail.com>
clalancette
added a commit
that referenced
this pull request
May 6, 2024
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 <prefix>/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. Signed-off-by: Chris Lalancette <clalancette@gmail.com> (cherry picked from commit 1839d58) Co-authored-by: Chris Lalancette <clalancette@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 Kitware/CMake@0a81110
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.