| Age | Commit message (Collapse) | Author |
|---|
|
REVIEW: 128780
|
|
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
|
|
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 prevents accidental "leaking" of symbols from internal code, such
as flex/bison generated parsers.
REVIEW: 124740
|
|
|
|
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.
|
|
|
|
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
|
|
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
|
|
|
|
http://techbase.kde.org/Projects/KDE_on_Windows/kf5/meetingnotes-2014-05-06
|
|
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
|
|
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
|
|
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).
|
|
kde_enable_exceptions() essentially does what
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${KDE_ENABLE_EXCEPTIONS}")
used to do. kde_target_enable_exceptions does it on a per-target basis.
|
|
Various defines we set affect the API offered by the system; subsequent
CMake configure checks should happen in a matching environment.
REVIEW: 115294
|
|
Setting the variable just leads to set() calls overwriting each other
accidentally (as appeared to have happened in the WIN32 block).
REVIEW: 114908
|
|
|
|
This originally found the manifest tool from kdewin, which was then used
by kde4_add_executable to embed a standard manifest file in
applications, apparently allowing applications to have administrator
privileges when run by an administrator.
Given we do not have kde4_add_executable any more, this is useless (and
certainly does not belong in this file).
kdewin should provide any relevant manifest macros itself, in a
KDEWinMacros.cmake file or some such, and these should be used on an
as-needed basis for executables that require it.
|
|
Set CMAKE_CXX_VISIBILITY_PRESET and CMAKE_VISIBILITY_INLINES instead
(which sets the default for all targets).
Note that the removal of include(GenerateExportHeader) means that this
will have to be explicitly included in the CMakeLists.txt of the
frameworks (as they use generate_export_header).
REVIEW: 114898
|
|
KDECompilerSettings.cmake no longer alters CMake's built-in build types
or adds its own. The "debug" build type therefore simply sets -g with
no additional flags (rather than -O2 and, depending on the compiler,
some no-inline/no-reorder flags as previously), the "release" build
types no longer set -DQT_NO_DEBUG and the "debugfull", "profile" and
"coverage" build types no longer exist.
QT_NO_DEBUG is set by Qt's CMake scripts depending on the build type of
Qt itself. "debugfull" mostly set -g3, allowing macro expansion when
debugging; users can set this flag using environment variables if they
wish. "RelWithDebugInfo" should be used instead of "profile" (according
to dfaure); -fprofile-arcs and -ftest-coverage are easy enough to add to
$CXX_FLAGS if they are required (formerly set by "profile" and
"coverage").
You should now use
cmake -DCMAKE_BUILD_TYPE=debug
instead of
cmake -DCMAKE_BUILD_TYPE=debugfull
CCMAIL: kde-frameworks-devel@kde.org
REVIEW: 114885
|
|
|
|
|
|
REVIEW: 114501
|
|
|
|
Please check...
CCMAIL: rakuco@FreeBSD.org
|
|
REVIEW: 113373
|
|
the kde libs.
|
|
Sharing compiler settings between GCC and clang does not always work: there
are flags (such as "-fno-check-new" or "-fno-reorder-blocks") that are
specific to GCC, and nothing stops these incompatibilities from becoming
bigger in the future.
Conversely, a separate clang block allows us to pass some additional flags
to clang that would have required yet another if() in the GCC block. For
now, this amounts to "-fdelayed-template-parsing".
(For KDE4, we also need -Wno-return-type-c-linkage because kdepim's
ktexteditorkabcbridge.cpp exports a function that returns a QString with C
linkage, but I hope this can be solved in a different way for kdepim5).
Last but not least, checks for bad GCC allocators or support for some flags
which are always present in clang can be avoided altogether when we know the
compiler we are using.
REVIEW: 112136
|
|
This more or less copies what was done for KDE4 in
https://git.reviewboard.kde.org/r/111612/.
With the changes applied I successfully installed a hello world
application. The linker and compiler command lines seem to be correct
and include all extended features. I also checked and debugfull also
works as expected (-g3 is added).
REVIEW: 111661
|
|
|
|
Author: Andrius da Costa Ribas <andriusmao@gmail.com>
Date: Sat Jun 15 09:51:41 2013 -0300
Patch CMake files for Intel compiler support on win32.
|
