Age | Commit message (Collapse) | Author |
|
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
|
|
|
|
REVIEW: 114336
|
|
Please check...
CCMAIL: rakuco@FreeBSD.org
|
|
REVIEW: 113373
|
|
the kde libs.
|
|
|
|
|
|
This is a new feature in CMake 2.8.12.
|
|
One of the most important things kde4_add_plugin was doing was stripping
MODULE targets from its prefix. This change makes it so those targets won't
get the prefix by default.
REVIEW: 112839
|
|
This is the old name for the setting below it. The old name was never
in a release.
|
|
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.
|
|
|
|
It is only needed for users of kde_file, so more it to a more
relevant place.
|
|
The CMAKE_BUILD_INTERFACE_INCLUDES is about to be renamed to that
name. The old name can be removed when we require a newer CMake.
|
|
|
|
On multi-config generators, that variable is not set, so cmake fails
on it.
|
|
|
|
CMake already knows the flag to use, and it is not always -fPIE.
See the output of git grep CMAKE_C_COMPILE_OPTIONS_PIE in cmake
for example. Therefore, there's no need to issue a message either.
|
|
http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7727
|
|
The only use of this was removed recently in 93457e172cf17a442938614cca1862a2dcfd889f
|
|
Qt 5 does not support it.
|
|
These are already set by add_compiler_export_flags which is invoked
below.
|
|
It is not clear whether the allocator is still 'bad' in more-recent
GCC versions, but let's pretend we know it is.
|
|
Same as 21c3f0bed3b758baefb9b760efb0c2dd by Patrick von Reth in kdelibs.
He says:
"dont disable auto-import, to make it possible to build with a newer mingw
which doesnt have proper exports for c++ standart libs
The problem occurs with all gcc versions newer then 4.4.
In preparation for Qt5 I started to work with newer builds, currently 4.7.2.
The change should not have any negative effects on 4.4 and earlier
versions, but is essential to make it build with a newer version."
Alex
|
|
This can be removed once we require cmake 2.8.11, then it will work
automatically.
Alex
|
|
Alex
|
|
Alex
|
|
Instead of testing for it, we can simply use the information provided
by Qt5 config.cmake files
Alex
|
|
Alex
|
|
-reenable the test for visibility in Qt
-reenable the test for FILE_OFFSET_BITS=64 (... there may be maybe some embedded systems where this is not the case ?)
-add -Wl,--disable-auto-import for mingw, we have that in FindKDE4Internal.cmake too
Alex
|
|
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
|
|
<thiago> that's an C++11-violating option. Time to stop using it.
(and Qt5.1's Q_GLOBAL_STATIC relies on it)
|
|
Alex
|
|
Alex
|
|
This only has an effect with CMake 2.8.11.
|
|
This will only have an effect with CMake 2.8.11, but until then,
it does no harm.
|
|
|
|
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
|
|
Alex
|
|
And qt plugins from lib/kde5/plugins to lib/plugins.
|
|
There was no reason to add more flags only on Linux/Hurd; in fact, in
kdelibs' FindKDE4Internal.cmake there's also a block with similar
settings for the BSDs.
Make it more general by removing the system checks before setting
these flags. -Wno-long-long is particularly needed when one is
building code with -pedantic (see picmi, for example).
CCMAIL: kde-buildsystem@kde.org
|