Web lists-archives.com

Re: kdesrc-build: PolkitQt5-1




On Wed, May 16, 2018 at 10:25:14AM +0200, gregor.mi.sw wrote:
> On 16.05.2018 05:17, Michael Pyne wrote:
> > On Tue, May 15, 2018 at 10:33:17AM +0200, gregor.mi.sw wrote:
> >> Hello Michael,
> >>
> >> I just started a full rebuild and closely watched the CMakeCache.txt files. There is one finding.
> >>
> >> $ # no special env var setup
> >> $ kdesrc-build --include-dependencies ksysguard kinfocenter kdevelop
> >>
> >> ...
> >>
> >> Building polkit-qt-1 from <module-set at line 34> (9/86)
> >>           No source update, but the build directory doesn't exist
> >>           Updating polkit-qt-1 (to branch master)
> >>           Source update complete for polkit-qt-1: no files affected
> >>           Preparing build system for polkit-qt-1.
> >>           Running cmake...
> >>           Compiling... succeeded (after 19 seconds)
> >>           Installing.. succeeded (after 0 seconds)
> >>
> >> Building kauth from frameworks (10/86)
> >>           No source update, but the build directory doesn't exist
> >>           Updating kauth (to branch master)
> >>           Source update complete for kauth: no files affected
> >>           Preparing build system for kauth.
> >>           Running cmake...
> >>           Compiling... succeeded (after 52 seconds)
> >>           Installing.. succeeded (after 0 seconds)
> >> ...
> >>
> >>
> >> In /home/gregor/kde/build/frameworks/kauth/CMakeCache.txt I have those lines:
> >>
> >> ...
> >> //The directory containing a CMake configuration file for KF5CoreAddons.
> >> KF5CoreAddons_DIR:PATH=/home/gregor/kde/usr/lib64/cmake/KF5CoreAddons
> >>
> >> //The directory containing a CMake configuration file for PolkitQt5-1.
> >> PolkitQt5-1_DIR:PATH=/usr/lib64/cmake/PolkitQt5-1
> >> ...
> >>
> >> which means KF5CoreAddons was found at the correct place whereas for PolkitQt5-1, it picked up the
> >> wrong location. I checke, those files are present:
> >>
> >> /home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1Config.cmake
> >> /home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1ConfigVersion.cmake
> >> /home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1Targets-debug.cmake
> >> /home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1Targets.cmake
> >>
> >> Any idea?
> > 
> > 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.
> > 
> > To avoid --refresh-build you can call "kdesrc-build --reconfigure kauth"
> > to re-run CMake first without deleting the build directory.
> > 
> > [1] https://cmake.org/cmake/help/latest/command/find_package.html
> > 
> > Regards,
> >   - Michael Pyne
> > 
> 
> Sadly, the test was negative...
> 
> $ sudo zypper install libpolkit-qt5-1-devel
> 
> $ kdesrc-build --reconfigure kauth
> 
> ### /home/gregor/kde/build/frameworks/kauth/CMakeCache.txt
> --- Problems --------------------------------
> PolkitQt5-1_DIR:PATH=/usr/lib64/cmake/PolkitQt5-1
> ---------------------------------------------
> 
> $ export CMAKE_MODULE_PATH=$HOME/kde/usr/lib64/cmake
> 
> $ kdesrc-build --reconfigure kauth
> 
> Same problem:
> 
> ### /home/gregor/kde/build/frameworks/kauth/CMakeCache.txt
> --- Problems --------------------------------
> PolkitQt5-1_DIR:PATH=/usr/lib64/cmake/PolkitQt5-1
> ---------------------------------------------
> 
> Removing the system devel package helps again:
> 
> $ sudo zypper remove libpolkit-qt5-1-devel
> 
> $ kdesrc-build --reconfigure kauth
> 
> ### /home/gregor/kde/build/frameworks/kauth/CMakeCache.txt
> OK

To be honest I'm mystified.

I thought that maybe CMAKE_MODULE_PATH wasn't good enough because, at
least on my system, PolkitQt5 doesn't actually install any Find* modules
and so there would be no advantage to setting that path after all.

In fact I went and pulled the OpenSuse package for libpolkit-qt5-1-devel
and verified that it doesn't contain any CMake modules anyways. So that
seems a dead end.

The next step is to check KF5::KAuth to see how it searches for
PolkitQt5. But that seems to be correct, since even if KAuth ended up
using a CMake module for this, it would find its own
cmake/FindPolkitQt-1.cmake module, and that module calls find_package()
with an explicit NO_MODULE declaration to force "config" mode to be
used, for which CMAKE_PREFIX_PATH should work.

There was one difference between the OpenSuse package and what PolkitQt5
installs on my system:

I have 4 "PolkitQt5-1*.cmake" files in my CMAKE_PREFIX_PATH (under
PolkitQt5), and so does the OpenSuse package.

But where I have a file "PolkitQt5-1Targets-release.cmake", the OpenSuse
package instead has "PolkitQt5-1Targets-none.cmake".

I believe that CMake uses CMAKE_BUILD_TYPE to help in choosing which of
these config files to load.... perhaps the "-none" config is a better
match than what would be provided when installing PolkitQt5 from
kdesrc-build?

I haven't been able to figure out from CMake docs or Internet searches
why CMake generates "-none" target configs but this may be related.

Regards,
 - Michael Pyne