Age | Commit message (Collapse) | Author |
|
|
|
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
|
|
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
|
|
|
|
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).
|
|
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
|
|
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
|
|
|
|
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
|
|
|
|
http://techbase.kde.org/Projects/KDE_on_Windows/kf5/meetingnotes-2014-05-06
|
|
This way, overriding LIBEXEC_INSTALL_DIR will change where frameworks
install libexec files in the expected way.
REVIEW: 118048
|
|
This is needed for e.g. kpluginfactorytest in kcoreaddons. Plugins are
searched relative to the directory containing the running executable and
before this commit the unit test was in ${CMAKE_BINARY_DIR}/bin and
the plugin dll in ${CMAKE_BINARY_DIR}/lib, which meant that it could not be
found. This was not a problem on Linux since there the unit test and the
plugin .so ends up in ${CMAKE_CURRENT_BINARY_DIR}.
Reviewed on #kde-windows
|
|
use CMAKE_[RUNTIME|ARCHIVE|LIBRARY]_OUTPUT_DIRECTORY. dlls and executables are built into the bin subdir and import & static libraries and plugins end up in the lib subdir of the build directory.
REVIEW:117965
|
|
REVIEW: 117682
|
|
This essentially reverts db553c810cbc3a446f90d4c962110d6262853cde. It
turns out that (for better or worse) quite a few places access files
without going through KFile, so it is worth making sure they can deal
with files larger than 2Gb on 32-bit systems.
Reviewed by: Harald Sitter <sitter@kde.org>
CCBUG: 165449
|
|
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.
|
|
Hopefully these might be of some use in determining whether they are
still needed.
|
|
All of KF5 + kate + kde-workspace compile with clang and -fno-exceptions
The only problem related to clang and -fno-exceptions I could find was
http://llvm.org/bugs/show_bug.cgi?id=10910 and that is fixed since
clang version 3.0 which was released in December 2011
REVIEW: 115395
|
|
|
|
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
|
|
REVIEW: 115477
|
|
This is cleaner and easier to read.
REVIEW: 115378
|
|
In particular, MSVC (and Intel on Windows) have no equivalent of the
-std flag to set the language standard, and Intel does not appear to
produce the warnings that were disabled for MSVC.
REVIEW: 115378
|
|
Previously we would end up with both /DEFAULTLIB:msvcrt and
/DEFAULTLIB:msvcrtd on the command line. As a result of the the programs
would link to both the debug and the release C library and always crash
soon after startup.
REVIEW: 115456
|