| Age | Commit message (Collapse) | Author |
|---|
|
We've had multiple people accidentally building KConfig without QML support and then complain that something down the line is breaking
To make that harder add an explict option to disable the QML stuff
|
|
This was built with:
-DQT_MAJOR_VERSION=6 \
-DEXCLUDE_DEPRECATED_BEFORE_AND_AT=5.90.0 \
-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x055a00
Move the include(KDEInstallDirs) call before the first find_package(Qt*,
the former is what auto-detects the Qt version, and defaults to 5. This is
needed to be able to build against Qt5 by default.
All unit tests still pass.
|
|
This way consumers which want to use the ConfigPropertyMap don't have to
pull in KDeclarative's entire dependency tree.
Also we can remove the automatic saving of the config, previously
this was opt-out - which makes is difficult to deprecate anything.
This way the API design is also more clear, since the object only takes care of exposing the
data to QML. The writing has to be done manually, which makes more sense anyways when we have
the notify opt-in.
As discussed on the KF6 weekly thread, an optional QML submodule is seen as the best
way to handle the QML dependency.
Task: https://phabricator.kde.org/T12131
Relates to https://phabricator.kde.org/T12126, after his change the KDeclarative stuff can be deprecated.
Because we don't register the property map in any QML plugin, there is
no conflict in duplicating and modifying it now.
|
|
|
|
Frameworks will be Frameworks 6 at some point and there is no good reason to have the major version in the variable name.
Given this is purely internal we can to this now, making it a bit more future-proof
GIT_SILENT
NO_CHANGELOG
|
|
|
|
GIT_SILENT
|
|
GIT_SILENT
|
|
GIT_SILENT
|
|
Summary:
This is particularly useful for cross-compilation, where we only need the
kconfig_compiler on the host system.
Reviewers: #frameworks, apol, aacid
Reviewed By: aacid
Subscribers: aacid
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D6994
|
|
Using the new extra-cmake-modules module ECMAddQch (since 5.36.0)
this adds the option to automatically build and install a file
in QCH format with the docs about the public API, which then can be
used e.g. in Qt Assistant, Qt Creator or KDevelop.
Additionally the installed cmake config files will be extended
with a target KF5Config_QCH containing information about how to "link"
into the generated QCH file, which then can be used in the cmake build
system of other libraries building on this library, by
simply listing this target in "LINK_QCHS" of their ecm_add_qch() usage.
And a respective doxygen tag file with all the metadata about the
generated QCH file and used for the "linking" will be created and
installed.
Pass -DBUILD_QCH=ON to cmake to enable this.
|
|
Generate-source-file macros should be used from the same CMakeLists.txt
file as the targets they generate files for.
|
|
like all the other Qt-based modules do
|
|
Drop KCoreAddons and KI18n dependency.
Add a bunch of QStringLiteral()
|
|
|
