| Age | Commit message (Collapse) | Author |
|---|
|
Summary:
Instead of using "share" use "${BIN_INSTALL_DIR}/data" on Windows,
this is the location provided by QStandardPaths for GenericDataLocation
on Windows.
Reviewers: dfaure
Reviewed By: dfaure
Subscribers: kfunk
Differential Revision: https://phabricator.kde.org/D1873
|
|
Better wait a little until applying this change, since this might break
assumptions, and we don't know yet if all distros are using a recent enough
AppStream (Generator) release.
This reverts commit 4b7a90bfe7a3e2eb3ae83c946c182a79fabc51e3.
|
|
As per AppStream release 0.9.4
|
|
Make Qt and ECM-based projects use the same directory sctructure (i.e.
where plugins are, libs, etc.) by default. Otherwise it creates a tiny mess
that might be controlled but usually won't.
In the end, otherwise, people need to keep adapting their systems with
environment variables anyway. All distros end up setting always this
setting as ON, as well as brave developers who don't have separate prefixes
for Qt and KDE.
REVIEW: 127169
|
|
templates are very useful as teaching tool in order to make
a minimal application that uses a certain framework.
templates in the KAppTemplate repository will always get forgotten
(plus kapptemplate is not really necessary as they work in kdevelop as well)
An ideal situation would be frameworks having templates in their own repos
with templates of barebone apps using the main framework features.
In order to do that, the cmake stuff needed in order to correctly install
a template needs to be ported to a place avaiable to all frameworks
REVIEW:126185
|
|
We recommend including KDE "settings" modules with NO_POLICY_SCOPE, both
so we can resolve this issue and to allow us to deal with similar things
in the future.
REVIEW: 126535
|
|
REVIEW: 126414
|
|
Example:
CMake Warning (dev) at
Z:/kderoot/share/ECM/kde-modules/KDEFrameworkCompilerSettings.cmake:50(elseif):
Policy CMP0054 is not set: Only interpret if() arguments as variables or
keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.
REVIEW: 126405
|
|
This reverts commit 1e8e0da3eb475bb8b78baa54cb0c34b913c2dc5d.
I don't want this going into a release without further review, as well
as documentation and tests, so I'm reverting it (at least temporarily).
See emails on kde-commits mailing list for further rationale.
CCMAIL: notmart@gmail.com
|
|
templates are very useful as teaching tool in order to make
a minimal application that uses a certain framework.
templates in the KAppTemplate repository will always get forgotten
(plus kapptemplate is not really necessary as they work in kdevelop as well)
An ideal situation would be frameworks having templates in their own repos
with templates of barebone apps using the main framework features.
In order to do that, the cmake stuff needed in order to correctly install
a template needs to be ported to a place avaiable to all frameworks
REVIEW:126185
|
|
REVIEW: 126090
|
|
from the normal qt.io installer on mac os
we can revisit this change, if it leads to problems for mac ports or homebrew
REVIEW: 125614
|
|
Reviewed at https://git.reviewboard.kde.org/r/125163/
|
|
This warning is emitted for every qCDebug() call and is not useful.
REVIEW: 125031
|
|
REVIEW: 124763
|
|
(they are slower). And enable them on MSVC now that we rely on Qt 5.3, as the comment said.
REVIEW: 124762
|
|
This prevents accidental "leaking" of symbols from internal code, such
as flex/bison generated parsers.
REVIEW: 124740
|
|
|
|
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
|
|
|
|
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
|
