The KDELibs4support framework has developed a surprise/hidden dependency on KEmoticons which doesn't show up in the CMake summary after configuring the framework. It also doesn't show up in the CMake summary printed after configuring a dependent like kio-extras - provide KEmoticons is available. Yet, when you configure kio-extras without having the KEmoticons framework available, the following error is generated: ``` -- Found KF5I18n: /opt/local/lib/x86_64-linux-gnu/cmake/KF5I18n/KF5I18nConfig.cmake (found version "5.35.0") -- Found KF5KIO: /opt/local/lib/x86_64-linux-gnu/cmake/KF5KIO/KF5KIOConfig.cmake (found version "5.35.0") CMake Warning at /opt/local/share/cmake-3.8/Modules/CMakeFindDependencyMacro.cmake:55 (find_package): By not providing "FindKF5Emoticons.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "KF5Emoticons", but CMake did not find one. Could not find a package configuration file provided by "KF5Emoticons" (requested version 5.35.0) with any of the following names: KF5EmoticonsConfig.cmake kf5emoticons-config.cmake Add the installation prefix of "KF5Emoticons" to CMAKE_PREFIX_PATH or set "KF5Emoticons_DIR" to a directory containing one of the above files. If "KF5Emoticons" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): /opt/local/lib/x86_64-linux-gnu/cmake/KF5KDELibs4Support/KF5KDELibs4SupportConfig.cmake:40 (find_dependency) /opt/local/share/ECM/find-modules/FindKF5.cmake:74 (find_package) CMakeLists.txt:26 (find_package) CMake Warning at /opt/local/share/ECM/find-modules/FindKF5.cmake:74 (find_package): Found package configuration file: /opt/local/lib/x86_64-linux-gnu/cmake/KF5KDELibs4Support/KF5KDELibs4SupportConfig.cmake but it set KF5KDELibs4Support_FOUND to FALSE so package "KF5KDELibs4Support" is considered to be NOT FOUND. Reason given by package: KF5KDELibs4Support could not be found because dependency KF5Emoticons could not be found. Call Stack (most recent call first): CMakeLists.txt:26 (find_package) -- Could NOT find KF5KDELibs4Support (found version "5.35.0"), checked the following files: /opt/local/lib/x86_64-linux-gnu/cmake/KF5KDELibs4Support/KF5KDELibs4SupportConfig.cmake (version 5.35.0) Reason given by package: KF5KDELibs4Support could not be found because dependency KF5Emoticons could not be found. -- Found KF5Solid: /opt/local/lib/x86_64-linux-gnu/cmake/KF5Solid/KF5SolidConfig.cmake (found version "5.35.0") -- Found KF5Bookmarks: /opt/local/lib/x86_64-linux-gnu/cmake/KF5Bookmarks/KF5BookmarksConfig.cmake (found version "5.35.0") -- Found KF5GuiAddons: /opt/local/lib/x86_64-linux-gnu/cmake/KF5GuiAddons/KF5GuiAddonsConfig.cmake (found version "5.35.0") CMake Error at /opt/local/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find KF5 (missing: KDELibs4Support) (found suitable version "5.35.0", minimum required is "5.3.0") Call Stack (most recent call first): /opt/local/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE) /opt/local/share/ECM/find-modules/FindKF5.cmake:110 (find_package_handle_standard_args) CMakeLists.txt:26 (find_package) -- Configuring incomplete, errors occurred! ``` I haven't checked when this hidden dependency was introduced. It will probably not affect most users who simply install all existing frameworks, but it can lead to surprises to packagers (who probably also have all frameworks installed). Build systems that print summaries like is custom for KF5 should ideally also check for runtime and equivalent dependencies and report even if they're satisfied.
Git commit 16d159e7b910080011a6405cab1739217ae68c80 by Michael Pyne. Committed on 01/07/2017 at 02:19. Pushed by mpyne into branch 'master'. Search for KEmoticons, which is a dependency per the CMake config.cmake.in. In fact it's been a dependency since 2014 if I'm reading the git annotate right. I've also updated the kde-build-metadata. FIXED-IN:5.36 M +1 -0 CMakeLists.txt https://commits.kde.org/kdelibs4support/16d159e7b910080011a6405cab1739217ae68c80
Thanks. I didn't yet look at the git blame data, but I'm not surprised the dependency has been there for quite a while. What I did do though is trying to find the actual dependency. There's none on the KEmoticons binaries, KDELibs4support apparently builds without KEmoticons installed so no dependency on header files either. Did you double-check if we're not dealing with a dangling dependency declaration or one that simply slipped in along with others that are relevant?
All I did was verify that kdelibs4support is actually checking for KEmoticons in its CMake config metadata and then add the corresponding check. I haven't checked whether kdelibs4support actually needs it, at build time or at run time, which needs a bit more investigative rigor than I have time to do. But if it turns out kdelibs4support doesn't need kemoticons, it's easy to remove both the check and the CMake config reference, and to adapt kde-built-metadata again.
KEmoticons was part of kdelibs4, so applications that are quickly ported using KDELibs4Support expect that KEmoticons is available.
That may well be, but I'd say they were ported a bit too quickly taking a bit too much of a shortcut. After all, the same argument applies to most of the KF5 frameworks...
Yes, that's intententionally. Developers can do a quick port using KDELibs4Support, or they can check the exact dependencies for each class they were using and stop linking to KDELibs4Support. Since KDELibs4Support depends on kio, it actually drags in most frameworks that were part of kdelibs4. The exceptions are kemoticons and kunitconversion. That's why these needed to be explicit dependencies.
I've always seen the main role of KDELibs4Support to provide wrappers for or implementations of old, deprecated classes, not to provide a Qt5-based rewrite of KDELibs...
If the relevant KF5 class is source-compatible with the KDE4-based equivalent, then preferring to make it a dependency of kdelibs4support (instead of unnecessarily adding porting work with additional "K4Emoticons" classes and similar) actually seems preferable to me.
The goal is that ultimately people port their projects to KF5 completely, build system included, no? That would favour obliging them to link with the required frameworks - something that's just a small change to the CMake files if the relevant classes indeed have the same API. But whichever approach is chosen, dependencies shouldn't be hidden like this one was. (FWIW, I probably made a bit more of a point of this because of the kind of framework we're talking about, one you cannot really call of crucial importance...)