This fixes bug 395627, where the error is actually that we set
CMAKE_PREFIX_PATH twice if qtdir is set to a non-system path and the
user is also setting CMAKE_PREFIX_PATH.
Unfortunately the second value overrides the first (the one the user
set).
Also added a test for this, which fails before the fix and passes
afterwards. The full test suite (all 5...) pass.
BUG:395627
FIXED-IN:18.08
Prior to this change, CMAKE_PREFIX_PATH was consistently set (which is
preferred for most find_package() calls) but CMAKE_MODULE_PATH was only
set for Qt5 (if Qt had a different prefix than the module being
installed).
This could lead to situations where "simplified" find_package() calls
would use "Module" mode (using CMAKE_MODULE_PATH) and end up falling
back to a search of system directories. This could result in finding the
wrong module if the module being searched for was installed on the
system.
Summary:
Ignore /usr as prefix or kdedir when prepending environment variables to not
overrule user setting of PKG_CONFIG_PATH.
For me it was enough to fix my build with prepending CMAKE_PREFIX_PATH
conditionally, but in theory the other environment variables should also only
be prepended if it is not /usr to prepend.
Test Plan:
Compiled XCB 1.13 to /opt/xcb and have XCB 1.11 in /usr/.... Set
PKG_CONFIG_PATH to /opt/xcb/lib/pkgconfig.
Without this patch CMake, called by kdesrc-build, finds XCB 1.11 in
/usr/lib/x86_64-linux-gnu according to its log, but sets as version number
1.13 for some reason.
On make this fails. It still uses the lib from /opt/xcb> but does not include
the correct headers in opt/xcb/include.
With the patch CMake directly finds the lib in /opt/xcb and build succeeds.
Reviewers: bshah, mpyne
Reviewed By: mpyne
Subscribers:
Tags:
Differential Revision: https://phabricator.kde.org/D12739
Summary: The qtdir config option from .kdesrc-buildrc was seemingly innefective, which is fixed by this patch
Reviewers: mpyne
Differential Revision: https://phabricator.kde.org/D11736
There is code to avoid using the TTY code that updates the status of the
build in the current line. This code prevents using the fancy TTY stuff
if progress output is not supported, but doesn't actually ever output
the end result of the build (success or failure), which wasn't the
intent.
In the other situations we don't want to clutter the line output with a
redundant status. Instead of duplicating the "progress output
supported" check later to output the status (or not), I just took out
the check for whether progress output is supported entirely, since the
progress callback can work even with build systems w/out support.
BUG:391396
FIXED-IN:18.04
Perl seems to have settled on the 'parent' module instead of manually defining
variables that tell the interpreter which packages to fall back to. Some
classes now use parent, some still use the old way.
Migrate everything over to be consistent.
Now we describe up-to-date module progress (if multiple modules are
being built) and consolidate muliple lines of information into just a
couple (for build and install).
This patch does three things:
1-Adds --install-only for the sake of consistency
2-Adds --install into the usage
3-Makes the CMake (KDE4) build system use make install/fast.
make install/fast only performs the installation of the files
thus avoiding a double compilation.
REVIEW: 116589
This can be used as a run-time check later to ensure that kdesrc-build
finds compatible versions of its component modules (though that isn't
done yet).