small adjustment to how a system-provided libCURL is searched for #86
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.
Description
We used
find_package(CURL CONFIG QUIET)
to pull in an externally provided libcurl-library, which means that CMake is only looking for package configuration files (CURLConfig.cmake or curl-config.cmake file). However, those files are not provided e.g. by Debian's 'libcurl4-openssl-dev'-package. So, we fall back to CMake's standard search procedure iffind_package(CURL CONFIG QUIET)
fails and try again withfind_package(CURL QUIET)
.This allows us to use the apt-package without further ado in building libCZI, saving quite some time compared to otherwise having to build libcurl ourselves (with vcpkg or as part of libCZI-build).
I chose to bump the version number here, in order to be able to mention this change in the changelog.
Type of change
How Has This Been Tested?
In a codespace
Checklist: