aboutsummaryrefslogtreecommitdiff
path: root/kde-modules/KDECompilerSettings.cmake
AgeCommit message (Collapse)Author
2021-10-10msvc: Fix __cplusplus valueAleix Pol
Ensure /Zc:__cplusplus is passed when using newer C++ standards. https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-160
2021-09-28Add -Werror=init-self to the default CMAKE_CXX_FLAGSAhmad Samir
Should help catch errors like initializing a q-ptr with itself[1]. [1] https://invent.kde.org/frameworks/knewstuff/-/commit/d09ba1917cb7e035a9aac6c27c86fc4df5da3194
2021-07-19Move ENABLE_BSYMBOLICFUNCTIONS documentation in its own moduleAleix Pol
2021-07-17Define NOMINMAX on WindowsHannah von Reth
This will prevent the macro definition of min and max which breaks the use of std::min and std::max
2021-07-16KDECompilerSettings: properly use KDE_QT_MODERNCODE_DEFINITIONS_LEVELFriedrich W. H. Kossebau
MO_CHANGELOG
2021-07-16KDECompilerSettings: support multiple inclusion and auto-levelsFriedrich W. H. Kossebau
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
2021-07-15KDECompilerSettings: fix message status on too high KDE_COMPILERSETTINGS_LEVELFriedrich W. H. Kossebau
Also print current values for more context NO_CHANGELOG
2021-07-13Fix typos found by codespellChristophe Giboudeaux
GIT_SILENT
2021-07-12Fix windows build on CIAhmad Samir
GIT_SILENT
2021-07-12Handle case where ECM_GLOBAL_FIND_VERSION is undefinedChristophe Giboudeaux
If no minimum ECM version is required, ECM_GLOBAL_FIND_VERSION is empty and the version comparison fails. Amends: 12af1e4e5
2021-07-12Enable the usage of -Bsymbolic-functionsAleix Pol
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.
2021-07-10KDECompilerSettings: add KDE_COMPILERSETTINGS_LEVEL & more settingsFriedrich W. H. Kossebau
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.
2021-06-28KDECompilerSettings: revert setting CMAKE_C(XX)_EXTENSIONSFriedrich W. H. Kossebau
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
2021-06-27cmake: Explicetely disable c/c++ compiler extensionsAlbert Astals Cid
We're a multi-compiler project, so disable compiler specific extensions
2021-05-25Clean ECM files after the minimum version changeChristophe Giboudeaux
- Remove deprecated version checks - Use VERSION_GREATER_EQUAL
2021-04-23Modules docs: move rst docs into bracket commentsFriedrich W. H. Kossebau
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
2021-04-14Fix static Windows builds by not setting /NODEFAULTLIB:libcmt /DEFAULTLIB:msvcrtHannah von Reth
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...
2021-01-02Tell MSVC that our source files are UTF-8 encodedv5.78.0-rc1v5.78.0Volker Krause
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.
2020-06-14extra-cmake-modules: Convert to SPDX license statementsAndreas Cord-Landwehr
2019-10-23Don't set C/C++ standards if already setDavid Faure
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
2019-10-22Use modern way to set the C/CXX standadHannah von Reth
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
2019-10-01new module ECMSourceVersionControlv5.63.0-rc2v5.63.0-rc1v5.63.0Harald Sitter
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
2019-07-23Make the default build type "Debug" when compiling a git checkout.David Faure
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
2019-03-23Revert "Take clang-cl into account"Christian Mollekopf
This reverts commit 2e1cb0c453f419da134b850052da6c804cae05e0. This was an accidental push to master, sorry for the noise.
2019-03-23Take clang-cl into accountChristian Mollekopf
2019-01-19Move -Wsuggest-override -Wlogical-op to regular compiler settingsAlbert Astals Cid
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
2018-11-12Use `MATCHES "Clang"` to detect clangRené J.V. Bertin
This is for compatibility with Apple's Xcode compilers which identify as AppleClang. Differential Revision: https://phabricator.kde.org/D16816
2018-09-01Revert "Add _XOPEN_SOURCE to C definitions"v5.50.0-rc1v5.50.0David Faure
This reverts commit 6684cb99bdf408fc491e547393dbd7aac4d151f2. See https://phabricator.kde.org/D8256 for details
2018-08-31Add _XOPEN_SOURCE to C definitionsA. Wilcox
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
2017-07-18KDECompilerSettings.cmake - handle Cywgin when setting LINK_FLAGSAllen Winter
Differential Revision: https://phabricator.kde.org/D6762
2017-06-15(always include CheckCXXCompilerFlag before calling it)R.J.V. Bertin
Mea culpa, the project I tested this with apparently used the macro too.
2017-06-15guess less, test moreR.J.V. Bertin
Don't attempt to guess whether (Apple) Clang 3.5 supports -Wdate-time, use CheckCXXCompilerFlag and be certain.
2017-06-14detect Xcode <= 6.2 from Clang version onlyR.J.V. Bertin
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.
2017-05-30restore hidden-visibility testing with Xcode 6.2v5.35.0-rc1v5.35.0R.J.V. Bertin
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.
2017-04-18KDECompilerSettings: Pass -Wvla & -Wdate-timeKevin Funk
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
2017-04-10Fix compilation under AppleClangKevin Funk
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
2017-04-05Use -Wno-gnu-zero-variadic-macro-arguments moreKevin Funk
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
2017-03-19KDE compiler settings: treat Clang and AppleClang equallyv5.33.0-rc1v5.33.0René J.V. Bertin
https://phabricator.kde.org/D5089
2017-01-16Pass -fno-operator-names when supportedKevin Funk
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
2016-12-29Enable colored warnings in ninja's outputElvis Angelaccio
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
2016-12-11Never use -Wl,--no-undefined on Mac (APPLE).R.J.V. Bertin
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)).
2016-12-10Accept AppleClang as an alternative to ClangR.J.V. Bertin
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
2016-10-08Revert "Teach KDECompilerSettings about clang-cl, a mode of Clang compiler ↵Ben Cooksley
that simulates MSVC." This reverts commit 4b8e8dcc8856d8f438860783e7641d02d1c05630.
2016-09-30Teach KDECompilerSettings about clang-cl, a mode of Clang compiler that ↵Gleb Popov
simulates MSVC. REVIEW: 128779
2016-08-31add full license textAllen Winter
REVIEW: 128780
2015-12-28Silence CMP0063 warnings with KDECompilerSettings.Alex Merry
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
2015-12-18Fix CMP0054 warningsKevin Funk
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
2015-08-16Also set the default visibility for C code to hidden.Volker Krause
This prevents accidental "leaking" of symbols from internal code, such as flex/bison generated parsers. REVIEW: 124740
2015-02-06Document when modules were added to ECM.Alex Merry
2014-11-14Update the comments about the default lib MSVC hacksv1.5.0-rc1v1.5.0Alex Merry
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.
generated by cgit v1.2.1 (git 2.18.0) at 2025-05-04 10:05:30 +0000