FS#68076 - [check]: invalid CMake config installed
Attached to Project:
Arch Linux
Opened by Matwey V. Kornilov (matwey) - Friday, 02 October 2020, 14:29 GMT
Last edited by Jan Alexander Steffens (heftig) - Saturday, 03 October 2020, 10:19 GMT
Opened by Matwey V. Kornilov (matwey) - Friday, 02 October 2020, 14:29 GMT
Last edited by Jan Alexander Steffens (heftig) - Saturday, 03 October 2020, 10:19 GMT
|
Details
Description:
/usr/lib/cmake/check/check-targets.cmake module fails due to missed libcheck.a file. The issue is that the module always checks for the file presence, even if this target is not used. Additional info: * check-0.15.2-1 Steps to reproduce: 1. Create sample CMakeLists.txt with the following content: cmake_minimum_required (VERSION 3.0) project(test LANGUAGES C) find_package(Check CONFIG NAMES Check check) 2. Create ./build dir and try to run cmake mkdir build cd build cmake .. 3. See the following error: -- The C compiler identification is GNU 10.2.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/sbin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done CMake Error at /usr/lib64/cmake/check/check-targets.cmake:96 (message): The imported target "Check::check" references the file "/usr/lib/libcheck.a" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib64/cmake/check/check-targets.cmake" but not all the files it references. Call Stack (most recent call first): /usr/lib64/cmake/check/check-config.cmake:36 (include) CMakeLists.txt:4 (find_package) -- Configuring incomplete, errors occurred! See also "/root/t/build/CMakeFiles/CMakeOutput.log". Possible solution: Patch check CMakeLists.txt during installation in order not to export Check::check static target. |
This task depends upon
Closed by Jan Alexander Steffens (heftig)
Saturday, 03 October 2020, 10:19 GMT
Reason for closing: Fixed
Additional comments about closing: check 0.15.2-2
Saturday, 03 October 2020, 10:19 GMT
Reason for closing: Fixed
Additional comments about closing: check 0.15.2-2
I'm not sure why this package builds with both cmake and autotools if the cmake files are broken anyway. Can we just drop that?
Alternatively is there a way to tell cmake to drop that broken check *without* patching unstable generated outputs, which I really do not think is remotely advisable.
Cmake config files are not even advised for use on linux since they are usually wrong and often not available for good or ill. Using pkg_check_modules is the "good practice" advice.
Please note that cmake doesn't say that it didn't found Check, it breaks inside find_package() function, so there is no way to check anything else as you suggested, because no further instruction are executed after find_package() line.
What I initially suggested, is to patch the sources (not generated output) as following to prevent generating libcheck.a related staff:
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 4a02dbe..4d731c9 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -188,7 +188,7 @@ target_include_directories(checkShared
)
if(NOT THIS_IS_SUBPROJECT)
- install(TARGETS check checkShared
+ install(TARGETS checkShared
EXPORT check-targets
ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
However, if you consider using cmake as a bad practice then you just shouldn't distribute /usr/lib/cmake/check at all.
Edit: note that it's still useful to check it as a fallback -- people might want to use your software but their system install of libcheck was built with autotools only.
Thank you for correcting me about the patch you suggested. I agree that if you can patch the source CMakeLists.txt to not try to generate broken static library checks, this is the best solution to the bug report.
Ideally we could get upstream to properly select for shared only, and also for cmake to stop breaking on unused files that are deleted in packaging. But if we can robustly work around it so that the cmake config files which are installed, are functional, we should do so.
...
Cmake config files still suck, but that's not a reason to refuse to install them. Merely a reason to warn people that they might not behave as expected...