Closed jengelh closed 1 year ago
Have you tried setting -DFETCHCONTENT_TRY_FIND_PACKAGE_MODE=ALWAYS
as described here?
I suppose I read it once years ago since some defines were in our .spec, but not read recently for 2.0. Oh well. :^)
For the record, this requires FETCHCONTENT_TRY_FIND_PACKAGE_MODE requires cmake 3.24.
This should be fixed by setting FIND_PACKAGE_ARGS argument in FetchContent_Declare() so that it tries to find it locally first. Then it will also work with cmake 3.14.
FetchContent_Declare(
...
FIND_PACKAGE_ARGS Confuse 3.3)
Then it should fist check if it is available on the system an fall back to download it otherwise.
See https://cmake.org/cmake/help/latest/module/FetchContent.html#integrating-with-find-package
This should be fixed by setting FIND_PACKAGE_ARGS argument in FetchContent_Declare() so that it tries to find it locally first. Then it will also work with cmake 3.14.
No, FIND_PACKAGE_ARGS
has been introduced with CMake 3.24, because that is the CMake version where the find_package()
integration was added.
Have you tried the following?
find_package(Confuse 3.3)
if (NOT Confuse_FOUND)
FetchContent_Declare(...)
endif()
I considered this early on, but decided against it. If someone gives me a compelling reason why they absolutely need to link against system libraries but cannot upgrade to a recent CMake, I might reconsider.
It is fairly simple. If you package software for Linux distributions, you have to use the system libraries! The build systems used by Fedora or openSUSE do not have an internet connection for security reasons.
If you want to package postsrsd current versions (like openSUSE 15.4, CentOS Stream 9) you don't have cmake 3.24 available, but you have cmake 3.14 which is also the minimum version set in the CMakeLists.txt.
postsrsd 2.x fails to consider an already existing libconfuse present in the system (at its usual location, e.g. /usr/lib*/pkgconfig/libconfuse.pc), causing the configure stage to needlessy hang for some time until dying off in a network-locked buildroot.