SUMMARY Fontconfig detection in plasma-desktop fails when compiling with cmake 3.14 STEPS TO REPRODUCE 1. >>> Configuring source in /var/portage/tmp/portage/kde-plasma/plasma-desktop-9999/work/plasma-desktop-9999 ... >>> Working in BUILD_DIR: "/var/portage/tmp/portage/kde-plasma/plasma-desktop-9999/work/plasma-desktop-9999_build" cmake -C /var/portage/tmp/portage/kde-plasma/plasma-desktop-9999/work/plasma-desktop-9999_build/gentoo_common_config.cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/usr -DBUILD_TESTING=OFF -DKDE_INSTALL_USE_QT_SYS_PATHS=ON -DKDE_INSTALL_DOCBUNDLEDIR=/usr/share/help -DCMAKE_DISABLE_FIND_PACKAGE_AppStreamQt=ON -DCMAKE_DISABLE_FIND_PACKAGE_Fontconfig=OFF -DCMAKE_DISABLE_FIND_PACKAGE_IBus=ON -DCMAKE_DISABLE_FIND_PACKAGE_Evdev=OFF -DCMAKE_DISABLE_FIND_PACKAGE_XorgLibinput=OFF -DCMAKE_DISABLE_FIND_PACKAGE_SCIM=ON -DCMAKE_DISABLE_FIND_PACKAGE_KF5Baloo=OFF -DCMAKE_DISABLE_FIND_PACKAGE_Synaptics=OFF -DCMAKE_BUILD_TYPE=Gentoo -DCMAKE_TOOLCHAIN_FILE=/var/portage/tmp/portage/kde-plasma/plasma-desktop-9999/work/plasma-desktop-9999_build/gentoo_toolchain.cmake /var/portage/tmp/portage/kde-plasma/plasma-desktop-9999/work/plasma-desktop-9999 loading initial cache file /var/portage/tmp/portage/kde-plasma/plasma-desktop-9999/work/plasma-desktop-9999_build/gentoo_common_config.cmake CMake Warning (dev) at gentoo_common_config.cmake:8 (SET): OBSERVED RESULT -- Found Fontconfig: /usr/lib/libfontconfig.so (found version "2.13.1") -- Warning: Property DESCRIPTION for package Fontconfig already set to "Fontconfig is a library for configuring and customizing font access", overriding it with "Font access configuration library" -- Warning: Property URL already set to "https://www.fontconfig.org/", overriding it with "https://www.freedesktop.org/wiki/Software/fontconfig" and then -- The following OPTIONAL packages have not been found: * Fontconfig, Font access configuration library, <https://www.freedesktop.org/wiki/Software/fontconfig> Needed to build font configuration and installation tools EXPECTED RESULT Fontconfig is found SOFTWARE/OS VERSIONS Linux/KDE Plasma: git master (available in About System) KDE Plasma Version: git master KDE Frameworks Version: git master Qt Version: 5.12.1 cmake version: 3.14.0 ADDITIONAL INFORMATION Removing /usr/share/ECM/find-modules/FindFontconfig.cmake solves the problem
mmmh, plasma-desktop uses the ECM module before the system Findfontconfig.cmake. cmake --trace confirms that. However, FindX11.cmake later calls find_package(Fontconfig)
@brad, any clue about this? plasma-desktop looks for Fontconfig using the ECM module, sets Fontconfig_FOUND then FindX11.cmake causes CMake to look again for it. Shouldn't the second find_package() call be ignored is such cases?
find_package(Fontconfig) called from inside CMake's own FindX11 module will use CMake's own FindFontconfig ignoring any other in CMAKE_MODULE_PATH. This is CMP0017's NEW behavior. That policy was introduced so that CMake's own modules are not broken by incompatible same-named modules provided by projects, as once happened with FindPackageHandleStandardArgs (with KDE, IIRC). FWIW, setting CMP0017 to OLD is NOT a solution and should not be done. CMake commit 40b3dba52995e2c0275ae1712a169173aed6fcbf introduced FindX11's use of the new FindFontconfig module. It could perhaps be guarded by `if(NOT Fontconfig_FOUND)` to avoid this problem but that could break in other ways if ECM's FindFontconfig is not sufficiently compatible with CMake's. > Shouldn't the second find_package() call be ignored is such cases? The module mode of find_package() has no such optimization (and often cannot in case the requested components change). It's up to the find module to skip work if the module is already found. This approach does assume that the same module will be loaded every time. It's unfortunate that this conflict occurs and I don't like letting CMake be the cause of breakage, but I don't know what CMake can do differently here. We have to be able to add new find modules and use them from our own modules. ECM may be able to work around this by modifying it's FindFontconfig to include CMake's copy when available and map inputs/outputs for compatibility.
> but that could break in other ways if ECM's FindFontconfig is not sufficiently compatible with CMake's. Well, I'm surprised by the CMake's FindFontconfig variables. they don't follow CMake's standards (FONTCONFIG_FOUND, FONTCONFIG_LIBRARY, FONTCONFIG_INCLUDE_DIR, FONTCONFIG_VERSION). https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#standard-variable-names suggests they should have the same casing as the ECM module (Fontconfig_FOUND, Fontconfig_LIBRARIES, Fontconfig_INCLUDE_DIRS, Fontconfig_DEFINITIONS, Fontconfig_VERSION). I believe our version is more standard-compliant :)
For reference, CMake's FindFontconfig was added here: https://gitlab.kitware.com/cmake/cmake/merge_requests/2487 and was based on one from KWin. If we were to switch to the CamelCase names would this problem be resolved?
yep, we reworked FindFontconfig to match the CMake standards before moving it to ECM. The current version is here https://cgit.kde.org/extra-cmake-modules.git/tree/find-modules/FindFontconfig.cmake ironically, it moved to ECM 3 weeks ago before the 5.57 release.
I've opened an upstream CMake issue for the variable name case: https://gitlab.kitware.com/cmake/cmake/issues/19094
Many thanks.
This issue will be fixed in CMake 3.14.1 (commit https://gitlab.kitware.com/cmake/cmake/commit/a3a1e69f8a8e6571bbb8c9257b401f04c22bd1e2)