On Wed, May 16, 2018 at 11:38:02AM +0200, gregor.mi.sw wrote: > On 16.05.2018 10:53, Christophe Giboudeaux wrote: > > Hi, > > > > On mercredi 16 mai 2018 05:17:02 CEST Michael Pyne wrote: > >> > >> The only thing that comes to mind is the possibility of using the > >> "CMAKE_MODULE_PATH" setting as well. > >> > >> From looking at the kdesrc-build code, we set CMAKE_MODULE_PATH for Qt > >> modules, but don't also do the same (by default) for the module being > >> built. > >> > >> For the majority of KDE code this shouldn't matter, as CMAKE_MODULE_PATH > >> is used for the "Module" mode of CMake's find_package(), which most code > >> no longer uses. Instead we use "Config" mode for most find_package() > >> calls (which uses CMAKE_PREFIX_PATH). See the find_package > >> documentation for details. [1] > >> > >> CMake will use "Module" mode by default for find_package() calls that > >> use the "simplified" syntax and for which it can find matching CMake > >> modules. In the right setup that means it's possible for CMake to find > >> different packages depending only on whether the find_package() call > >> uses a simplified or complex syntax, which could explain why some > >> modules found the wrong module and some did not. > >> > >> To confirm this, you could try exporting CMAKE_MODULE_PATH to something > >> like "$HOME/kde/usr/lib64/cmake" manually, before running kdesrc-build > >> for kauth. Though I'm planning just to modify kdesrc-build to set the > >> variable regardless just in case. > >> > > CMAKE_MODULE_PATH ? really ? exporting it should be considered bad practice. > > CMake will ignore it anyway. > > > > The only way to tell CMake where to find stuff is CMAKE_PREFIX_PATH and > > nothing else. > > Hmm, do you have an idea then why CMake fails to do so correctly in some > cases like the KAuth module?
I ran into one more potential issue earlier today, related to CMAKE_BUILD_TYPE as I'd worried about in an earlier email on this thread. Basically, I had a module that I had inadvertently built with a different build type than the rest of KF5. Things kept working because I had a leftover old CMake config file with a matching build type. i.e. I had something like: ~/kde-5/lib64/cmake/KF5Solid +- KF5SolidConfig.cmake (new, wrong build type) +- KF5SolidConfigVersion.cmake (new, wrong build type) +- KF5SolidTargets.cmake (new, wrong build type) +- KF5SolidTargets-release.cmake (stale, right build type) \- KF5SolidTargets-noconfig.cmake (new, wrong build type) When building the rest of KF5, any modules that had Solid as a dependency would do a find_package() call for Solid, CMake would "find" it (using the stale) file, and things would work fine since it was the same soname and location either way. This finally broke for me when I removed the old libKF5Solid.so.5.42.0 I had. CMake still found the stale config file, but the config file itself raised an error when it couldn't find the matching .so. In a situation with a user/system CMake config split, it seems that if you have a mismatch with CMake build types then you could end up with a CMake config entry in the system path being a perfect match for a find_package() request even though there's a compatible CMake config entry earlier in CMAKE_PREFIX_PATH. In this scenario it's not good enough to have CMAKE_PREFIX_PATH set right, you have to make sure to consistently use the same CMAKE_BUILD_TYPE for all modules so that CMake searches for the right install configuration. --- My error stemmed from my kdesrc-buildrc, I had the equivalent of: module-set kf5 repository kde-projects use-modules frameworks cmake-options -DCMAKE_BUILD_TYPE=Release end module-set options solid cmake-options -DUSE_FOO=ON -DUSE_BAR=ON end options The cmake-options entry for solid here doesn't add to its default flags, it *replaces* them, which meant no -DCMAKE_BUILD_TYPE option was passed to CMake. I'm trying to think of how best to handle this going forward. Best option is probably to have a specific "cmake-build-type" option, or even a generic "build-type" option and let each kdesrc-build build system do the right thing from there. I could also try to come up with a syntax to append option values instead of setting them (kdesrc-build used to do this, but it was then hard to *remove* unwanted option values...). Regards, - Michael Pyne
