| Age | Commit message (Collapse) | Author |
|---|
|
CHANGELOG: extra-cmake-modules versioning is now aligned with KDE Frameworks.
Therefore the last release was 1.8, while this one is 5.9.
|
|
|
|
Through a quirk of implementation, old-style icon filenames are accepted
by the new-style ecm_install_icons function. It's too late to change it
now, as that would break existing projects, but we can warn about it.
REVIEW: 122941
|
|
The motivation behind this change is my distribution moving to a multiarch layout. While the architecture specific stuff (binaries, libraries, etc.) is installed under /usr/${host}/{bin,lib,...} architecture-independent data should still be installed to /usr/share/.
REVIEW: 122929
From 014d2166e08cbe6f350a8600a93c8f132ee95661 Mon Sep 17 00:00:00 2001
From: Heiko Becker <heirecka@exherbo.org>
Date: Fri, 13 Mar 2015 12:26:31 +0100
Subject: [PATCH] Allow configuration of SHARE_INSTALL_DIR
|
|
There is no "\t" in CMake's regular expression syntax; we need to make
the character be interpreted when CMake parses it as a string.
|
|
Qt5LinguistToolsConfig.cmake defines CMake target for lconvert since Qt 5.3.1,
so we should use that if it is available.
Our own hacks were not working in some configurations (i.e. when there is
/usr/bin/lconvert managed by qtchooser, but no qtchooser configuration file).
REVIEW: 122626
|
|
In particular, strongly recommend looking at the equivalent CMake
documentation with regard to PATH_VARS, as a lot of projects that should
be making use of it are not.
|
|
|
|
REVIEW: 122317
Thanks alexmerry and dvratil for review
|
|
Debian likes to install qt binaries into an obscure path, search here as well
REVIEW: 122526
|
|
|
|
|
|
|
|
Three modules (ECMCoverageOption, ECMEnableSanitizers and
ECMGeneratePkgConfigFile) were not being documented. This commit fixes
that situation.
|
|
|
|
Introduces the new Android toolchain file for being able to easily compile
our cmake projects in Android, with an emphasis on Qt projects.
CHANGELOG: New Android toolchain support module.
REVIEW: 121545
|
|
REVIEW: 122359
|
|
This is basically just the code available on the CMake FAQ item about
`make uninstall`, but packaged up in a convenient module.
REVIEW: 122359
|
|
|
|
BUG: 341683
FIXED-IN: 1.7.0
REVIEW: 121999
CHANGELOG: KDEInstallDirs: warn about mixing relative and absolute
installation paths on the command line
|
|
This reverts commit 959c374c022394a116e8ceb2b1fce2df11752068.
I merged and pushed the wrong branch.
|
|
SameMajorVersionWithPreleases is intended implement the versioning
scheme followed by many KDE projects: minor releases after some high
number (eg: 90) are considered to be pre-releases of the next major
version, and are not compatible with the current major version. This
allows alpha and beta releases to be ordered correctly by
version-number-aware software like package managers (an alpha of version
2 should have a higher number than any release of version 1, but less
than version 2.0).
So a request for version 2.1.0 of a piece of software should not be
satisfied by 2.93.4, because that is actually a pre-release of version
3. On the other hand, a request for version 2.91.0 should be satisfied
by version 3.1.0.
Note that prereleases are not considered unless explicitly requested, so
2.93.4 will not satisfy requests for version 3 (or version 2) of a piece
of software.
|
|
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
|
