| Age | Commit message (Collapse) | Author |
|---|
|
Semantically this is an ECM module, because it can be used to manage deprecated
Qt API and from any project which use ecm_generate_export_headers
|
|
This will make setting the deprecation versions easier, otherwise one would need
to edit the hex value. It also helps to keep the required versions and deprecation versions
in sync.
Also this allows one to keep the deprecation warnings, when one excludes deprecations for a specific version.
Additionally the deprecation version can be overwritten by a cmake parameter.
This will make local testing easier, because one does not need to edit the CMakeLists.txt files.
Task: https://phabricator.kde.org/T15109
|
|
So far we were defining e.g. KSERVICESDIR next to KDE_INSTALL_KSERVICES5DIR
here, rather than the intended KDE_INSTALL_KSERVICESDIR.
|
|
This enables forward-compatibility with KDEInstallDirs6.cmake
This was partly done already, but in the wrong order and not for all
versioned variables.
|
|
There is no path out of QtVersionOption.cmake that would let
QT_MAJOR_VERSION undefined, so this check is unnecessary. Worse, this
doesn't actually check for QT_MAJOR_VERSION being defined, but whether
a variable named after the content of the QT_MAJOR_VERSION variable is
defined. That is always false, so this effectively forces Qt5 and breaks
Qt6 support.
This reverts commit 8fd79163a7c60386fbc94bc14ca4a3b0b29d7227.
|
|
This fixes an infinite recursion of KDEInstallDirs including
itself when QT_MAJOR_VERSION is not defined.
|
|
and use only KSERVICESDIR in KDEInstallDirs6.
|
|
|
|
|
|
+ adjust docu
|
|
|
|
This factors out large parts of the common code into separate modules,
and adds a backward compatibility wrapper.
The 6 variant drops some deprecated variables where possible, but otherwise
is the same as the 5 variant. It still lacks a replacement for the paths
depending on ECMQueryQMake though.
|
|
This breaks older clang-format version :/
This reverts commit 81f70c9639154dcd067d73b0620767d8ba0362cf.
|
|
This is only supported in the latest clang-format version.
Having formatting enabled would cause it to complain about no rules
being set for json files.
|
|
|
|
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
|
|
I was seeing `error: No such remote 'origin'` in the cmake output.
This commit avoids hardcoding `origin` as the upstream URL and instead
uses the `git rev-parse @{u}` to get the configured upstream.
As a follow-up we may want to check if this should be executed by default,
but for now this fixes a warning that I'm seeing with various projects.
|
|
wl_resource_for_each_safe is used in kwayland-server, and as the name
suggests is a for-each like function.
|
|
|
|
If people ship their own clang-format file they might still have the copyright, because
they forked it. Instead search for the notice that the file is autogenerated.
|
|
Git on Windows provides bash
|
|
With non-GNU tar, passing the --sort option may print out an
error message saying the option isn't supported; that's
confusing and not useful to the consumer.
|
|
|
|
This will prevent the macro definition of min and max which breaks
the use of std::min and std::max
|
|
Also add trigger to switch to KDE_COMPILERSETTINGS_LEVEL of latest
KDECompilerSettings on ECM dependency in KF modules to 5.85
NO_CHANGELOG
|
|
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
|
|
No longer needed, also triggering wrong warning about
KDE_COMPILERSETTINGS_LEVEL value for 3rd-party users requiring older ECM
NO_CHANGELOG
|
|
GIT_SILENT
|
|
NO_CHANGELOG
|
|
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.
|
|
Has to wait until KF requires ECM 5.85.0
This reverts commit e6f87fa7427a2edde7dd8a47ace21011169d2650.
NO_CHANGELOG
|
|
NO_CHANGELOG
|
|
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.
|
|
Otherwise recent versions of git will complain with:
```
hint: The '.git/hooks/pre-commit' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
```
|
|
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
|
|
NO_CHANGELOG
|
|
|
|
But only for repos that require Frameworks 5.83 or newer.
We have asked on the KDE distributions mailing list and distro maintainers
didn't object to the change (since most distros already have recent enough
compilers).
|
|
to make build results deterministic
See https://reproducible-builds.org/ for why this is good.
related to
https://phabricator.kde.org/D25494
Without this patch, openSUSE's kio package varied in
/usr/share/kdevappwizard/templates/ioslave.tar
This PR was done while working on reproducible builds for openSUSE.
|
|
|
|
This check fixes a probably rare case, where we land in a repository
that contains this clang-format.sh hook but where the format file went
missing. In such cases, clang-format falls back to the system defaults,
which brings undesired defaults, e.g. enforced line breaks in comments
after 90 chars, which cannot easily be reverted by a reformat.
Since clang-format's --fallback-style=none option is not available for
git clang-format, this comment reimplements the logic.
|
|
- Remove deprecated version checks
- Use VERSION_GREATER_EQUAL
|
|
In case one has uninstalled the project, but has made local changes that
should be tested the test would fail. Instead check if the files exist
before adding them to the list of files that will be tested.
|
|
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
|
