| Age | Commit message (Collapse) | Author |
|---|
|
This adds an application icon to an executable from PNG files for
Windows and Mac OS X. Unlike the similar kde4_add_app_icon macro from
kdelibs, this requires icons to be explicitly listed as arguments
(meaning CMake can tell when ones are added or deleted and reconfigure
as appropriate), and it works with Matthias Benkmann's png2ico tool, as
well as the KDE-Win tool of the same name.
Currently missing unit tests. Also completely untested (except that
`make test` runs on Linux, so there are no obvious syntax errors).
With thanks to Ralf Habacker for the inital work on porting
kde4_add_app_icon.
CHANGELOG: Add ECMAddAppIcon module to add icons to executable targets
on Windows and Mac OS X.
|
|
With CMake 3.1, @-style variable expansion is deprecated outside of
configure_file() or string(CONFIGURE) contexts (CMP0053). This causes
ecm_generate_pri_file() to produce dev warnings with this verison of
CMake, and would break this function in projects that set CMake 3.1 as
their required version.
REVIEW: 121971
|
|
|
|
Cache variables such as CMAKE_INSTALL_BINDIR may be used by other
modules included from parallel parts of the tree, so we should not touch
them. We still override them in the runtime environment, but this will
not interfere with parallel subtrees of the project.
As part of this, the order of precedence of variables specified on the
command line is changed, so that KDE_INSTALL_* is considered first
(although it is still considered "undefined" in the documentation). This
means that if you only specify CMAKE_INSTALL_BINDIR, that will be used
by both KDEInstallDirs and GNUInstallDirs, but if you specify both that
and KDE_INSTALL_BINDIR, KDEInstallDirs will use KDE_INSTALL_BINDIR
instead. This is probably not too useful, but seems more useful than
any other arrangement.
BUG: 342717
REVIEW: 121982
|
|
|
|
|
|
A previous commit inadvertantly changed the KF5 include prefix to kf5
(uppercase to lowercase).
|
|
Mostly just refatoring to have less duplicated code.
|
|
REVIEW: 121646
|
|
REVIEW: 121646
|
|
Creating variables whose names start with CMAKE_ is a bad idea for
modules distributed outside CMake itself. Since the module is called
KDEInstallDirs, having a KDE_INSTALL_ prefix for the variables is clear
and intuitive.
Both CMAKE_INSTALL_* variables and the older KDELibs4-compatible
variables are provided, unless KDE_INSTALL_DIRS_NO_DEPRECATED is set to
TRUE before the module is included. Even then, the CMAKE_INSTALL_*
variables provided by the GNUInstallDirs module will still be set and
understood (for compatibility with that module), unless
KDE_INSTALL_DIRS_NO_CMAKE_VARIABLES is set to TRUE.
REVIEW: 121646
|
|
|
|
Lots of libraries will want to use SameMajorVersion to make sure
searching for version 1 of a library doesn't give you version 2, for
example.
We may want to add another, custom compatibility mode for
KDE Frameworks-style versioning, where version x.90.z to x.99.z are
alpha/beta releases for version (x+1).
REVIEW: 121696
|
|
|
|
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 #include in the main.c file did not match the generated header file
name, so it was actually incorrectly including the header from another
test.
BUG: 341576
|
|
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.
|
|
Having done a lot of (unrelated) Windows development recently, I've come
to understand the situation much better, so I'm recording that
information here for the benefit of others.
|
|
When installing to /usr, we should use /etc for configuration. Using
/usr/etc does not make sense.
REVIEW: 120246
|
|
While the search is unlikely to succeed on Windows, having different
behaviour between the platforms (eg: find_package(Wayland REQUIRED) was
not fatal on Windows, even though Wayland_FOUND would always be FALSE)
is not ideal, and if someone did port them to Windows for some reason,
the find modules should support that.
If applications actually want different behaviour between platforms
(like requiring a module on Unix, but not on Windows), they should
implement that logic themselves (since they will have to deal with
targets not being defined, etc, anyway).
REVIEW: 120481
|
|
|
|
|
|
|
|
REVIEW: 120655
|
|
Add a couple of find modules for wayland-scanner and qtwaylandscanner.
These modules find the respective executables and create a target that
points to the executable.
Targets are respectively Wayland::Scanner and Wayland::QtScanner.
There are also macros to generate C protocols with wayland-scanner and
C++ wrappers with qtwaylandscanner.
REVIEW: 120034
|
|
GIT_SILENT
|
|
when running with the KDE_INSTALL_USE_QT_SYS_PATHS option allow QMLDIR in
KDEInstallDirs to follow whatever is defined by qmake
this change makes sure that qml plugins will end up in a default Qt path
when using the super special magic flag.
|
|
add FindLibGit2.cmake + doc link
scripts tries to detect version not by pkgconfig to work on windows without pkgconfig, too
REVIEW: 120196
|
|
|
|
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).
|
|
Introduces a BUILD_COVERAGE option from a ECMCoverageOption file so that
projects can easily enable code coverage in their applications.
Furthermore, KDECompilerSettings does include that by default, so all
proper KDE projects have the option by default.
REVIEW: 120118
|
|
REVIEW: 119968
|
|
A new module has been introduced to generate pkgconfig files from
cmake projects.
REVIEW: 119798
|
|
|
|
|
|
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
|
|
Defining _XOPEN_SOURCE to 500 is too restrictive: it corresponds to
_POSIX_C_SOURCE 199506L, and hides several symbols that standard
libraries like libc++ expect to find, leading to errors like this on
FreeBSD:
In file included from /tmp/attica/src/accountbalance.cpp:21:
In file included from /tmp/attica/src/accountbalance.h:25:
In file included from /usr/local/include/qt5/QtCore/QString:1:
In file included from /usr/local/include/qt5/QtCore/qstring.h:50:
In file included from /usr/include/c++/v1/string:437:
In file included from /usr/include/c++/v1/string:437:
/usr/include/c++/v1/cstdio:143:9: error: no member named 'snprintf' in the global namespace
using ::snprintf;
~~^
This isn't a problem on Linux (actually, on systems using glibc) because
defining _GNU_SOURCE enables a lot more features that are not made
available on other libc implementations where it does not have any
effect.
Instead, stop defining _XOPEN_SOURCE at all and leave it up to the
platform to show or hide as many symbols as necessary if no
standards-related defines are set, and only set _GNU_SOURCE on systems
where it is actually meaningful (ie. systems using glibc).
REVIEW: 119696
|
|
|
|
The original purpose of this was to set the QT_NO_DEBUG macro if the old
DebugFull configuration was used. We got rid of DebugFull (instead just
using Debug), so it is no longer relevant, and this hack never belonged
in ECMConfig.cmake anyway (it should have been in KDECompilerSettings).
CHANGELOG: ECM now works when the required CMake version is set to
3.0.0 or higher, and does not require Qt5Core to be available.
BUG: 331849
REVIEW: 119588
|
|
|
|
Since PyQt 4.10, PyQt.pyqtconfig is deprecated and not available unless
PyQt is built using the old configure script.
PyKDE4 itself has recently been adjusted to mimic PyQt itself and only
install its pykdeconfig module if pyqtconfig is present. Additionally,
information such as SIP flags and the directory where PyKDE's SIP files
are installed are now also provided in the
PyKDE4.kdecore.PYKDE_CONFIGURATION dict.
This commit completely rewrites FindPyKDE4.py to make it look like
FindPyQt.cmake after commit a7e4743: most of the information used by
FindPyKDE4.cmake is fetched from PyKDE4.kdecore, and we first try to
obtain the SIP flags and directory from pykdeconfig and, if it fails, we
use PYKDE_CONFIGURATION.
Furthermore, FindPyKDE4.py now only prints the variables that are
actually consumed by FindPyKDE4.cmake -- it is not possible to obtain
all the data provided by pykdeconfig in PYKDE_CONFIGURATION. We've also
stopped reading and setting PYKDE4_VERSION_TAG, since PyKDE4 stopped
setting a KDE tag in 2008 (and its value was 3_92_0 at the time).
(Forwardport kdelibs 4d29cf8)
|
|
sys.prefix should be used instead of sys.platform
Forward port of kdelibs commit 8b1abe25dcf243cd2cdf23dff7272aca921292ae
|
|
PYQT4_SIP_DIR is a directory, not a file.
Forwardport of kdelibs/37f31f9ce39569a1096e5a04b6679a91e6ae18fe.
|
|
This way, on the Debian versions of these OSes, the library directory
can be a multiarch path.
|
|
REVIEW:118020
|
|
The version committed in 0912b24 is slightly different from the one in
kdelibs -- besides a few differences in the comments, there is an IF()
check that was always evaluating to false.
|
|
with PyQt's new build system."
REVIEW:119339
|
|
This now forwards to the buildsystem mailing list.
|
|
Otherwise, if lconvert exists in normal system paths (eg. /usr/bin) that one
will be used instead of the one alongside Qt5::lrelease. This could cause Qt4
lconvert to be incorrectly used on some systems.
REVIEW: 119198
|
