| Age | Commit message (Collapse) | Author |
|---|
|
ECMQueryQmake will fail as it's designed to only work with Qt5. We
don't want to terminate the execution there, just to spit a warning
and leave. If we suggest qmake-qt5 as a command, we'll end up performing
the call anyway.
This will fix the ExecuteCoreModules test under latest-qt4 build.
|
|
Addresses its usage on systems where Qt5 isn't installed, it allows for
modules using it to decide what they should do.
REVIEW: 128488
|
|
In case it fails, offer an error message and the attempted call, to make
sure we can react accordingly.
Note that the proper error argument is FATAL_ERROR, not FATAL.
REVIEW: 124106
|
|
81627ad86d3d7d5e5a7d130dfc746d5b1b58cbe7 broke the case where Qt5 qmake
is not in the path or not called qmake-qt5, because it stopped using the
location of qmake as provided by the Qt5Core CMake module when found.
|
|
The wrong syntax for set() was being used. This change also allows
QMAKE_EXECUTABLE to be used to override the qmake path even when the
Qt5Core CMake module is found.
|
|
We were keeping the \n after the path, and it would crash in some
places. Strip the whitespaces in both ends.
Reviewed by Rohan Garg
|
|
KDE modules cannot assume the normal ECM modules are in the CMake module
path, and CMAKE_INSTALL_IMPORTS_INSTALL_DIR / QTQUICKIMPORTSDIR was not
set correctly. Also, ECMQueryQmake.cmake used a deprecated CMake command
(exec_program).
|
|
Packagers and other interested folks should pass -DKDE_INSTALL_USE_QT_SYS_PATHS=ON
when building in order to install various files to the same dir as the Qt5 install
dirs.
CCMAIL: kde-packagers@kde.org
REVIEW: 119901
|
