Age | Commit message (Collapse) | Author |
|
|
|
This should catch undefined preprocessor expressions, i.e. instead of
showing a warning if FOO_BAR_H is undefined:
#if FOO_BAR_H
make the build fai lwith an error instead.
This combined with using #cmakedefine01 (instead of #cmakedefine), could
catch things like:
https://invent.kde.org/pim/kdepim-runtime/-/commit/05a0e5bbfbb06ed6aa88640f25f563cf7e5b1330
|
|
Should help readers being aware of pitfalls
NO_CHANGELOG
|
|
NO_CHANGELOG
|
|
NO_CHANGELOG
|
|
OpenBSD has a similar patch inside the ports, see
Allow KDE5 libraries to be built without having to link to libc explicitly.
Index: kde-modules/KDECompilerSettings.cmake
--- kde-modules/KDECompilerSettings.cmake.orig
+++ kde-modules/KDECompilerSettings.cmake
@@ -530,6 +530,8 @@ endfunction()
# Better diagnostics (warnings, errors)
############################################################
+set(ALLOW_UNDEFINED_LIB_SYMBOLS No CACHE BOOL "allow undefined symbols in generated shared objects")
+
if ((CMAKE_CXX_COMPILER_ID STREQUAL "GNU" AND NOT APPLE) OR
(CMAKE_CXX_COMPILER_ID MATCHES "Clang" AND NOT APPLE) OR
(CMAKE_CXX_COMPILER_ID STREQUAL "Intel" AND NOT WIN32))
@@ -537,9 +539,11 @@ if ((CMAKE_CXX_COMPILER_ID STREQUAL "GNU" AND NOT APPL
set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--fatal-warnings ${CMAKE_SHARED_LINKER_FLAGS}")
set(CMAKE_MODULE_LINKER_FLAGS "-Wl,--fatal-warnings ${CMAKE_MODULE_LINKER_FLAGS}")
- # Do not allow undefined symbols, even in non-symbolic shared libraries
- set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--no-undefined ${CMAKE_SHARED_LINKER_FLAGS}")
- set(CMAKE_MODULE_LINKER_FLAGS "-Wl,--no-undefined ${CMAKE_MODULE_LINKER_FLAGS}")
+ if (NOT ${ALLOW_UNDEFINED_LIB_SYMBOLS})
+ # Do not allow undefined symbols, even in non-symbolic shared libraries
+ set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--no-undefined ${CMAKE_SHARED_LINKER_FLAGS}")
+ set(CMAKE_MODULE_LINKER_FLAGS "-Wl,--no-undefined ${CMAKE_MODULE_LINKER_FLAGS}")
+ endif()
endif()
set(_KDE_GCC_COMMON_WARNING_FLAGS "-Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef")
|
|
Ensure /Zc:__cplusplus is passed when using newer C++ standards.
https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-160
|
|
Should help catch errors like initializing a q-ptr with itself[1].
[1] https://invent.kde.org/frameworks/knewstuff/-/commit/d09ba1917cb7e035a9aac6c27c86fc4df5da3194
|
|
|
|
This will prevent the macro definition of min and max which breaks
the use of std::min and std::max
|
|
MO_CHANGELOG
|
|
Existing projects have muliple calls of find_package(ECM) and
include(KDECompilerSettings), usually in pairs, e.g. for forks of
3rd-party software or examples.
While this is not a recommnended setup, as there is no official
mechanism to properly reset previously created setings, those
existing projects and their releases can be supported by
discarding any auto-level values at the end of the include,
so the next can pick up again the value of any closer
find_package(ECM) call.
NO_CHANGELOG
|
|
Also print current values for more context
NO_CHANGELOG
|
|
GIT_SILENT
|
|
GIT_SILENT
|
|
If no minimum ECM version is required, ECM_GLOBAL_FIND_VERSION is empty
and the version comparison fails.
Amends: 12af1e4e5
|
|
Checks if the compiler supports it and if so it enables it by default.
This is useful as it allows to perform internal linking operations at
build time that otherwise would have been delayed until process startup
time.
|
|
There is desire for having more strict compiler settings by default over
what the KDECompilerSettings have been declaring until now. This means
making more use of modern features usually and being less
tolerant about the use of deprecated ones.
While some projects have used KDEFrameworksCompilerSettings to get more
modern requirements by just a single macro include, that was not the
intent of that module, and now is also warned about in the docs.
Instead of adding a new separate dedicated module e.g. named
KDEStricterCompilerSettings, with a separate version scheme for sets
of strict settings, the existing KDECompilerSettings macro file is instead
extended as well as are the ECM versions reused to define the different
sets of settings. As these settings are getting more strict by the time,
e.g. allowing less of old & deprecated code, these sets are considered as
kind of levels.
To enable the clients to control the required settings level, a
dedicated variable KDE_COMPILERSETTINGS_LEVEL is introduced, which
for convenience defaults to the minimum required ECM version, so only
needs to be set when the need for other newer features provided by ECM
does not go along the settings level of that ECM version.
As some projects might have needs not exactly matching a certain settings
level, additionally the settings can be optionally individually
controlled by specific variables, to be set again before including
KDECompilerSettings.
|
|
Some projects using KDECompilerSettings need more control about whether
this is set, as 3rd-party projects linked to might not meet those
requirements.
To be reworked and added later with consumer control options
|
|
We're a multi-compiler project, so disable compiler specific extensions
|
|
- Remove deprecated version checks
- Use VERSION_GREATER_EQUAL
|
|
CMake >= 3.0 supports bracket comments, and the reStructuredText
integration code in sphinx/ext/ecm.py already supports extracting
the docs from a bracket comment instead.
Editing documentation without leading line comment markers is more simple,
e,g. when reflowing text over lines.
With ECM meanwhile requiring CMake 3.5 now it is possible to switch
(and thus follow also the approach used by cmake itself).
NO_CHANGELOG
|
|
If we tell the compiler to link the runtime statically and then explicitly link
the dynamic runtime and prohibit the static we continue to produce dynamic
builds...
|
|
For GCC/Clang that is the default, but not for MSVC. This can cause both
compile-time and runtime errors when encountering string literals that
contain more than just 7bit ASCII.
Some of our modules set this already, others use various other workarounds
to avoid Utf-8 literals, so better do this consistently and centrally.
Qt6 will also set this by default.
This is actually Hannah's finding from debugging issues caused by this
in kitinerary, I'm just submitting the patch.
|
|
|
|
Summary: Fixes regression from https://phabricator.kde.org/D24841
Reviewers: cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D24882
|
|
Summary:
This allows later modification of the selected standard.
Raise C from C89 to C90 as C89 is not supported by the CMAKE flag
https://cmake.org/cmake/help/v3.16/prop_tgt/C_STANDARD.html#prop_tgt:C_STANDARD
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D24841
|
|
Summary:
simply sets a variable when the source is under version control. use it to
auto-enable Debug builds. there are also plans to switch special assertion
logic on in KIO when used from git, so there definitely is a more generic
use case of wanting to control behavior based on whether it the source is
likely used to make a development or production build.
conceivably the module could be used in the future to get git rev-parse or
the like, hence the generic name.
Test Plan: with .git the var is true, without it is false
Reviewers: kde-buildsystem, dfaure
Reviewed By: dfaure
Subscribers: apol, kossebau, kde-frameworks-devel
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D24159
|
|
Summary:
The idea comes from
https://blog.kitware.com/cmake-and-the-default-build-type/
but I adapted it to leave it empty for tarballs, to avoid messing up
distribution packaging.
The goal is to make this more sensible for [new] developers who just
run cmake and end up with a "no debug symbols, no optimizations" build,
i.e. the one and only completely useless combination of those two flags.
Possible risk: distributions who compile from git checkouts...
Test Plan: "mkdir build ; cd build ; cmake .." in kblog leads to CMAKE_BUILD_TYPE=Debug
Reviewers: kde-buildsystem, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: cgiboudeaux, apol, kde-frameworks-devel
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D22667
|
|
This reverts commit 2e1cb0c453f419da134b850052da6c804cae05e0.
This was an accidental push to master, sorry for the noise.
|
|
|
|
Summary: They really help making the code better so it's good to have all applications getting those warnings
Subscribers: apol, vkrause, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D18167
|
|
This is for compatibility with Apple's Xcode
compilers which identify as AppleClang.
Differential Revision: https://phabricator.kde.org/D16816
|
|
This reverts commit 6684cb99bdf408fc491e547393dbd7aac4d151f2.
See https://phabricator.kde.org/D8256 for details
|
|
When building on non-glibc Unix platforms, such as Solaris, NetBSD, and Linux/musl or Linux/uclibc, multiple components of KF5 fail to build. This is because -std=iso9899:1990 is specified (for strict C90 compliance) but _XOPEN_SOURCE is not defined, so none of the POSIX interfaces are exported. I have seen this reported in at least:
* kinit
* kscreenlocker
* plasma-workspace
The attached patch resolves this issue on all our build boxes; additionally, applying it to my glibc builder did not change the already working result.
BUG: 373175
Differential Revision: https://phabricator.kde.org/D8256
|
|
Differential Revision: https://phabricator.kde.org/D6762
|
|
Mea culpa, the project I tested this with apparently used the macro too.
|
|
Don't attempt to guess whether (Apple) Clang 3.5 supports -Wdate-time,
use CheckCXXCompilerFlag and be certain.
|
|
This modifies 340b969f54d2f271e925ed7f84c831e1e4b2ccd0 by testing for
Xcode <= 6.2 using the AppleClang version scheme only, to account for
rare conditions where the compiler ID is not AppleClang.
|
|
Xcode 6.2 (OS X 10.9.5) has a Clang version that is based on Clang 3.5 but does
not yet support -Wdate-time . Commit 7af9f8e2b6eb235923a329e8ff24012883fb6b86
introduced a regression where this compiler failed to pass the visibility tests
because it prints a warning about -Wdate-time. This in turn leads to linker
errors.
|
|
Summary:
-Wvla: Warn because it's non-standard feature, not supported by MSVC to date
-Wdate-time: Warn because using __TIME__ or __DATE__ prevents reproducible builds
These warnings are being used for *building* Qt itself as well (cf.
qt_common.prf in qtbase)
Test Plan: No new warnings from rebuilding KDE Frameworks
Reviewers: mpyne
Reviewed By: mpyne
Subscribers: mpyne, #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5430
|
|
Summary:
Broken since we started to treat Clang and AppleClang differently (with
the switch to CMake 3.0)
FIXED-IN: v5.34.0
BUG: 377933
Reviewers: apol, rjvbb
Reviewed By: apol, rjvbb
Subscribers: #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5379
|
|
Summary:
Add it to KDECompilerSettings.cmake instead of
KDEFrameworkCompilerSettings.cmake.
Users can then just enable -pedantic without worrying about the
gnu-zero-variadic-macro-arguments warning.
This fixes some warnings in e.g. kdenlive
Reviewers: kossebau, apol, dfaure
Reviewed By: apol
Subscribers: apol, #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5302
|
|
https://phabricator.kde.org/D5089
|
|
Summary:
Disables alternative tokens for &&, ||, etc.. They're are not supported
by MSVC out of the box, thus using them will limit the portability of
the code. There *are* options to make alternative tokens available under
MSVC [1], but I think we shouldn't promote the usage of them.
From the GCC documentation:
-fno-operator-names: Do not treat the operator name keywords and,
bitand, bitor, compl, not, or and xor as synonyms as keywords.
[1] http://stackoverflow.com/questions/555505/when-were-the-and-and-or-alternative-tokens-introduced-in-c
Reviewers: #frameworks, #buildsystem, ivan
Reviewed By: ivan
Subscribers: rakuco, elvisangelaccio
Differential Revision: https://phabricator.kde.org/D3850
|
|
Summary:
Colored compiler warnings in ninja output only work with the
`-fdiagnostics-color=always` flag.
See https://github.com/ninja-build/ninja/issues/814 for a rationale.
This commit adds such flag in ecm for gcc >= 4.9 and clang >= 3.5,
and only if the CMAKE_GENERATOR is Ninja.
Test Plan: ninja+gcc and ninja+clang now show nice colored compiler warnings.
Reviewers: #frameworks
Differential Revision: https://phabricator.kde.org/D3733
|
|
While unusual it is not impossible to use GCC on Macs, esp. not when
using older OS X versions. Intel also makes compilers for Mac, so it may
in fact be better to rewrite the check ((GNU or Clang or Intel) IF NOT
(APPLE or WIN32)).
|
|
Apple's clang v3.1 corresponds to clang 3.1 and started following the
Xcode versioning scheme from 4.4 onwards (though loosely). An overview
of the version correspondance can be found here:
https://gist.github.com/yamaya/2924292
|
|
that simulates MSVC."
This reverts commit 4b8e8dcc8856d8f438860783e7641d02d1c05630.
|
|
simulates MSVC.
REVIEW: 128779
|