| Age | Commit message (Collapse) | Author |
|---|
|
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).
|
|
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
|
|
|
|
ECM_GENERATE_PRI_FILE() creates a .pri file for a library so that qmake-based
apps can more easily use the library.
It also sets ECM_MKSPECS_INSTALL_DIR as the directory to install the .pri file to.
REVIEW: 115099
|
|
This makes it easier for other functions to access the project version,
for instance my upcoming ECM_GENERATE_PRI_FILE()
|
|
On MSVC linker errors will happen when this flag is set (with Qt < 5.3)
REVIEW: 115234
|
|
This behaviour can be overriden by passing the GUI flag to the command
REVIEW: 115211
|
|
Setting the variable just leads to set() calls overwriting each other
accidentally (as appeared to have happened in the WIN32 block).
REVIEW: 114908
|
|
This appears to be a hangover from the KDE4 days, which would adjust
certain paths to match the ones for kdelibs if you installed an
application to the same prefix as kdelibs. This was probably to make
KStandardDirs work properly in unusual setups.
REVIEW: 114904
|
|
REVIEW: 115012
|
|
REVIEW: 114888
|
|
version
This is all internal, doesn't change the API or effects of ecm_setup_version.
|
|
Three groups seems excessive, but they all seem like they should be
there. Steve, do you have any opinion on this?
CCMAIL: steveire@gmail.com
|
|
We do not want to suppress any warnings about LINK_INTERFACE_LIBRARIES
vs INTERFACE_LINK_LIBRARIES; everything should be using the latter,
since we depend on CMake 2.8.12 everywhere.
REVIEW: 114903
|
|
|
|
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.
|
|
The old comments were somewhat out-of-date.
|
|
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
|
|
Reviewed by: Aurélien Gâteau <agateau@kde.org>
|
|
|
|
|
|
headers
|
|
RELATIVE is needed because some projects have their headers (and sources)
split into different subdirectories.
REQUIRED_HEADERS gives the opportunity to receive a list of all the headers
we're depending on, in case the user wants to re-use it.
|
|
|
|
REVIEW: 114501
|
|
Since some cmake modules include others inside e-c-m we need to set the cmake module path
so that they are found
|
|
|
|
REVIEW: 114336
|
|
Please check...
CCMAIL: rakuco@FreeBSD.org
|
|
Create ECM_GENERATE_HEADERS, a cmake function that will generate the
forward headers like we used to, in cmake configure time.
REVIEW: 113406
|
|
REVIEW: 113522
|
|
I can't find any use of it, which is semi-expected. It is replaced
by CMakePrintHelpers.cmake in CMake upstream.
|
|
The functionality of it is now provided by a KF5Config.cmake file.
Remember to remove it from your install prefix to avoid future
confusion.
CCMAIL: kde-frameworks-devel@kde.org
|
|
REVIEW: 113373
|
|
|
