| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
|
|
REVIEW: 113483
|
|
|
|
|
|
|
|
|
|
the kde libs.
|
|
|
|
|
|
|
|
It does not work with CMake master.
|
|
There is no need for the package to tell us its install dir.
|
|
It is redundant and obsolete.
Some frameworks can have erroneous values (eg KConfigWidgets currently
sets FooBar_LIBRARIES). Downstreams are expected to use the imported
target name instead.
CCMAIL: kde-frameworks-devel@kde.org
|
|
It is redundant and obsolete. The framework template does not set it.
|
|
|
|
|
|
These are not used anywhere.
|
|
This is a new feature in CMake 2.8.12.
|
|
As agreed.
CCMAIL: kde-frameworks-devel@kde.org
|
|
|
|
|
|
ecm_add_test was renamed eventually, but all uses weren't adapted
|
|
|
|
|
|
|
|
|
|
Every framework in KF5 has a macro similar to these, this reduces
the unnecessary duplication inside all of the frameworks
REVIEW: 112828
|
|
|
|
|
