Age | Commit message (Collapse) | Author |
|
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
|
|
- Only warn if the compiler is not recent enough (it may still work...)
- Bump up the GCC version to 4.5 (on Linux, at least) to match Qt
- Add checks for Windows (both MSVC and MinGW)
- Add check for Clang
REVIEW: 115372
|
|
Not that anyone is likely to use different compilers for C and C++...
REVIEW: 115379
|
|
When COMPILE_FLAGS is not set, get_source_file_property(flags ${source_file}
COMPILEFLAGS) set flags to "NOTFOUND". Leading to interesting build failures in
kde-runtime when we then set flags to "NOTFOUND -fexceptions", see
http://build.kde.org/job/kde-runtime_frameworks_qt5/58/
REVIEW: 115376
|
|
REVIEW: 115363
|
|
I am reasonably sure the allocator check is out of date, given our
minimum GCC version, and it was not used for anything interesting
anyway.
The visibility check will not be performed in practice, as this file
will almost always be included before any check for Qt.
REVIEW: 115360
|
|
|
|
This is entirely unnecessary with any sane toolchain, and should be in
the linker flags (rather than the compiler flags) for any system where
it is required.
REVIEW: 115362
|
|
|
|
Very little should have changed in practice (apart from the Intel
compiler stuff being properly separated between things for WIN32 and
things for other platforms, and not defining _BSD_SOURCE).
|