| Age | Commit message (Collapse) | Author |
|---|
|
In KF 5.90 we already looking for 5.15.2
and looking something lower than that
is a bit meaningless
|
|
The main target consumers of this macro currently (should) want to be
informed about new deprecations as early as possible. As do the authors
of the warnings.
So instead let's make no warnings an opt-in. Not documenting the
now deprecated flag in the docs, given no wide-spread use yet, just
supporting still in the code with a note to users.
|
|
|
|
This got messed up when refactoring the value from an one-value-keyword to an option.
|
|
NO_CHANGELOG
|
|
Complements 6f8e9ff84b959ba763fcff18f0c519075ea1df03
NO_CHANGELOG
|
|
Should help readers being aware of pitfalls
NO_CHANGELOG
|
|
NO_CHANGELOG
|
|
NO_CHANGELOG
|
|
NO_CHANGELOG
|
|
NO_CHANGELOG
|
|
NO_CHANGELOG
|
|
NO_CHANGELOG
|
|
Given ECM is released tightly bundled with KF, which itself requires
Qt 5.15 now, and no Linux distribution is known by repology.org which
ships older Qt, but current ECM, that support is considered of no more use.
|
|
Given ECM is released tighly bundled with KF, which itself requires
Qt 5.15 now, and no Linux distribution is known by repology.org which
ships older Qt, but current ECM, that support is considered of no more use.
|
|
|
|
The use of set_package_properties() requires the include, which might
not have been done by the macro consumer.
|
|
|
|
QQmlImportDatabase::resolvePlugin doesn't accept lib prefixes under
Windows, causing to fail to import when using as a dynamic plugin.
Inspired by kirigami!34
|
|
This means removing the find_program() logic, since it was only useful if
we don't want to make CMake spend time finding a compiler; so it was only
useful for building modules that don't need a compiler at all, wallpapers,
icon themes ...etc; so find_program() is only useful when it comes before
the find_package() and enable_language() calls. Thanks to Christophe
Giboudeaux for the explanation. This might make the build time for such
modules a tiny bit longer, but it's worth it to make finding qmake/qtpaths
|
|
Fix finding qmake when executable has no version suffix
|
|
Like is done in the Qt5 qmake code path.
|
|
Some applications look for ECM and need to know Qt paths but
don't need to link to anything. That's the case for icons or
wallpapers.
For these cases, ECMQueryQt will first try to find qmake or
qtpaths before looking for Qt CMake config files.
Also handle cases where project() sets 'LANGUAGE' to 'NONE'.
The CXX language needs to be enabled for find_package to look
for Qt into library dirs.
|
|
|
|
Which is a drop-in replacement, one just needs to replace query_qmake with
ecm_query_qt.
Copied the deprecation code from ECMQMLModules.cmake, saved a bit of
research time on how to do that in CMake.
|
|
Continuation of commit 4e47b053c9d799.
All unittests still pass.
|
|
Basically copied ECMQueryQmake to ECMQueryQt, added copyright based
on git log, with the BSD 3-clause license; based on the contents of the
README.rst file at the initial commit (commit 96e7fb9969b7 by Rohan Garg) of
ECMQueryQmake, the README file says:
All code is licensed under the BSD 3-Clause license.
Will CC active devs in the MR and email Rohan Garg to confirm.
Then added qtpaths CMake code path, basically you can use query_qt with Qt5
(same syntax, so a drop-in replacement for query_qmake); and Qt6.
The plan is to deprecate ECMQueryQmake in favour of the new module (had to
be done that way as the old module had "qmake" in the name and that could
be a bit confusing).
|
|
|
|
|
|
|
|
This reverts commit abc3a698abc0dfea19040007a7c57d04c3bb6865.
Unfortunately it caused various problems:
- Minimum cmake version for extra-cmake-modules does not contain the
required module
- Even with newer cmake it had issue with old policy that was not fixed
until very late that breaks packages using old policy
CCMAIL: kde-frameworks-devel@kde.org
|
|
Finding Qt6 tools without also finding any library component only works
in the COMPONENT form, see also MR !233.
Fixes issue #7
|
|
|
|
If linker does not support the linker flag, do not enable it, on alpine
e.g. musl does not support the ASAN, if it is enabled unconditionally,
it will cause the linker to error out
|
|
This is apparently needed for static QML plugins to work properly.
|
|
When the major version of a module is >1, Qt expects a .MajorVersion
suffix on the module path. Since we are already doing this for the
shared library install path, extract that code to a shared macro and
reuse it for the prefix path in the generated qrc.
|
|
|
|
To avoid ambiguity with ECMQmlModule.cmake.
To preserve backward compatibility, we keep a version around of
ECMQMLModules.cmake that warns a user of it being moved and includes the
new file.
|
|
This contains some helper functions to make it easier to create QML
modules through CMake. It takes care of several things that currently
need to be done manually.
It adds four tests for the four primary ways that it can be used,
either as shared/static library and with or without C++ plugin.
|
|
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
|
|
|
|
As discussed in [1], it's simpler to put the files in builddir/bin/, i.e.
no /plugins subdir, this makes it easier to run the unittest directly from
the CLI/debugger/IDE, without relying on ctest exporting the correct
QT_PLUGIN_PATH; instead QCoreApplication::libraryPaths() will pick up the
plugins in e.g. builddir/bin/kf5/kio/ automatically.
This will be followed by a change in KCoreAddons to remove the /plugins/ dir
from the path in the builddir.
[1] https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/213
|
|
It was missing the "/plugins" suffix; found while building KIO with Qt6,
where many unittests were failing with "couldn't create slave" for all slaves;
the kio slaves are in builddir/bin/plugins/kf5/kio, and KPluginMetaData
searches the directory "kf5/kio", and since it's a relative path, it assumes
it's in the "plugins" dir.
Keep the old behaviour for repos that put the plugins in builddir/bin/
directly without a "plugins" dir.
|
|
This doesn't make all these modules actually work with Qt6 yet, but it
prevents them from unconditionally pulling in Qt5 in a Qt6 build.
This is useful in order to even be able to pass a CMake run to the
point one can port, test and debug the rest.
|
|
While porting a manual configure_file invocation for kactivities'
.pc file to ecm_generate_pkgconfig_file I noticed that the URL keyword
was missing afterwards.
|
|
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.
|
|
The description was a bit misleading and may have suggested that
ksvg2icons was required for @2x (Retina) icons to work.
|
|
|
|
When cross-compiling QT_INSTALL_BINS contains binaries for the target
system that can't be used during the build. Instead use QT_HOST_BINS
which contains the Qt build tools for the current system.
|
|
While debugging a failing test (KProcessTest in KCoreAddons), I noticed
that the Q_ASSERT() statements inside that test weren't being executed
because RelWithDebInfo builds default to passing -DQT_NO_DEBUG.
With this change the test I was debugging now asserts early instead of
failing a QCOMPARE later on.
|
