[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: kdesrc-build: PolkitQt5-1
From: Christophe Giboudeaux <christophe () krop ! fr>
Date: 2018-05-16 8:53:06
Message-ID: 6611215.XiLIjPD5W1 () yuuko
[Download RAW message or body]
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.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic