| Age | Commit message (Collapse) | Author |
|
|
|
BUG: 341683
FIXED-IN: 1.7.0
REVIEW: 121999
CHANGELOG: KDEInstallDirs: warn about mixing relative and absolute
installation paths on the command line
|
|
|
|
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).
|
|
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
|
|
When installing to /usr, we should use /etc for configuration. Using
/usr/etc does not make sense.
REVIEW: 120246
|
|
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.
|
|
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
|
|
This way, on the Debian versions of these OSes, the library directory
can be a multiarch path.
|
|
REVIEW:118020
|
|
See RR 119142 for more details.
|
|
REVIEW: 118127
|
|
This matches how CMake's GNUInstallDirs does things.
REVIEW: 118057
|
|
|
|
This way, overriding LIBEXEC_INSTALL_DIR will change where frameworks
install libexec files in the expected way.
REVIEW: 118048
|
|
REVIEW: 117935
|
|
REVIEW: 117907
|
|
|
|
This is where applications install plugins, so "kf5" is incorrect.
Software should use application- or framework-specific directories
(which may or may not be versioned).
|
|
Also provide a subdirectory specific to kf5 that will put them in
lib/libexec/kf5
|
|
|
|
KNotifications will look here for .notifyrc files.
|
|
kde5/services is kservices5
kde5/servicetypes is kservicestypes5
|
|
This provides versioning in a way that is simple to update for KF6, and
reduces our footprint in /usr/share.
|
|
Only frameworks should be installing in include/KF5. They use
KF5_INCLUDE_INSTALL_DIR, which has the KF5 suffix, while other code
should install to just include (or a subdirectory of their choice).
|
|
Currently, this is the same as INCLUDE_INSTALL_DIR, but
INCLUDE_INSTALL_DIR will lose the "KF5" suffix once the frameworks are
changed to use KF5_INCLUDE_INSTALL_DIR. Because INCLUDE_INSTALL_DIR is
used in INSTALL_TARGETS_DEFAULT_ARGS, there is now also a
KF5_INSTALL_TARGETS_DEFAULT_ARGS.
|
|
|
|
This is deliberately modelled very closely on CMake's documentation
system. It's a hefty patch, because it involved changing all the
documentation to be in reStructuredText format. I also cleaned up the
copyright/license statements at the same time.
Note that the find modules contain the full license, due to the fact
that ecm_use_find_module() copies them out of the ECM distribution.
|
|
REVIEW: 115488
|
|
Given that binaries are all installed in PREFIX/bin, and have to avoid
clashes, doing the same for desktop files is no great issue, and
installing into a subdirectory of applications/ just complicates matters
for client code that needs to refer to the desktop file (is it
"kde5-foo[.desktop]", "kde5/foo[.desktop]" or just "foo[.desktop]"?).
REVIEW: 115683
|
|
This appears to be a hangover from the KDE4 days, which would adjust
certain paths to match the ones for kdelibs if you installed an
application to the same prefix as kdelibs. This was probably to make
KStandardDirs work properly in unusual setups.
REVIEW: 114904
|
|
REVIEW: 114336
|
|
This is a new feature in CMake 2.8.12.
|
|
Alex
|
|
This patch adds a variable QML_INSTALL_DIR, pointing to the location to
install QtQuick2 imports. These are co-installable with QtQuick 1.x, so
we need both dirs. Naming is consistent with the path, so IMPORT is
ditched from the name (the path doesn't have imports in it anymore).
REVIEW:1088889
|
|
This commit
-adds the macro ecm_setup_version(), as proposed on the kde-frameworks list
-sets CMAKE_INSTALL_DEFAULT_COMPONENT_NAME to ${PROJECT_NAME} if a project has been set
-makes e-c-m require cmake 2.8.10.1
Alex
|
|
And qt plugins from lib/kde5/plugins to lib/plugins.
|
|
|
|
|
|
including applying fixes I made to FindKDE4Internal but got lost in the
conversion:
* Use XDG dir for config files
* Make the "data" resource point to share rather than share/apps, in order
to match XDG_DATA_DIRS and QStandardPaths::GenericDataLocation.
Also, move autostart to the xdg path (etc/xdg/autostart).
|
|
Alex
|
|
KDEInstallDirs.cmake is similar to GNUInstallDirs.cmake coming with cmake,
but provides the install variables as used by KDE.
It also provides the special feature of initializing them to the values from kdelibs (?)
when installed into the same prefix.
Currently it all still uses "kde4", I'm not sure this will stay this way.
Alex
|