| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
|
|
- 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
|
|
When building multiple KDE projects, installing them to "$DESTDIR"
and having cmake look for kde dependencies in "$DESTDIR" using
"CMAKE_PREFIX_PATH=$DESTDIR/usr", we currently get failures when
calling find_package() on projects that use KDE_INSTALL_QTPLUGINDIR,
KDE_INSTALL_QTQMLDIR and KDE_INSTALL_QTQUICKIMPORTSDIR because these
are defined as absolute paths when KDE_INSTALL_USE_QT_SYS_PATHS is
enabled.
This commit defines these paths relative to qmake's QT_INSTALL_PREFIX
property instead when KDE is install to the same prefix as Qt. This
fixes DESTDIR installations because with relative paths, CMake will
search for these paths in "$DESTDIR" as well as "/".
We limit this change to the scenario where the Qt and CMake install
prefixes are the same because always doing this would break backwards
compatibility as qml and plugins would be installed into CMAKE_INSTALL_PREFIX
instead of QT_INSTALL_PREFIX after this change.
|
|
NO_CHANGELOG
|
|
Just like the app templates the file templates have a specific install
location.
Also the KTEMPLATESDIR is only used as a fallback, because it suggests
that all templates are in that dir, which is not true.
|
|
|
|
|
|
Systemd searches
"/usr/local/lib/systemd/user",
"/usr/local/share/systemd/user",
USER_DATA_UNIT_PATH,
"/usr/lib/systemd/user",
"/usr/share/systemd/user",
LIBDIR could be lib or lib64, so we need to be explicit here.
Reviewed on D25107
|
|
|
|
Summary: Like we have for other FD.O projects like DBus service files
Test Plan:
Unit test passes
Used in another project, and it installed to the correct place
Reviewers: apol
Reviewed By: apol
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D25107
|
|
Port of upstream commit https://gitlab.kitware.com/cmake/cmake/commit/18365587c86396f988e256b5acf4d2312f3be2bb
Differential Revision: https://phabricator.kde.org/D23497
|
|
Summary:
This follows where Qt installs those, and thus androiddeployqt looks for
them. Currently this is hardcoded in knotifications for example, seems
cleaner to have this here.
Reviewers: #build_system, #android, apol
Reviewed By: #android, apol
Subscribers: apol, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D23131
|
|
Summary:
It's especially when KDE_INSTALL_USE_QT_SYS_PATHS=OFF that the different environment variables will have to be initialised.
This adds a message that should tell users about the script so they have a hint of what is going on.
Reviewers: #frameworks, albertvaka, cgiboudeaux
Reviewed By: albertvaka, cgiboudeaux
Subscribers: cgiboudeaux, albertvaka, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D22580
|
|
Summary: If no prefix is passed, use ECM's by default, instead of defaulting to /usr/local which isn't optimal in any case.
Reviewers: cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: cgiboudeaux, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D22676
|
|
Summary: kdebugsettings categories files
Reviewers: dfaure, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: kossebau, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D21313
|
|
|
|
Summary:
It's not a thing on flatpak and it makes packaging weird.
Should fix https://github.com/flatpak/freedesktop-sdk-base/issues/22
Reviewers: #frameworks, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: cgiboudeaux, eszlari, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D13102
|
|
Summary:
Otherwise we hit a weird code path on androiddeployqt. This is what the official SDK looks like anyway:
```
$ ls /opt/Qt/5.10.1/android_armv7/
bin doc include jar lib mkspecs plugins qml src translations
```
Reviewers: vkrause
Reviewed By: vkrause
Subscribers: #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D12269
|
|
Summary:
If enabled it will install a prefix.sh script to the root of the prefix.
This file will be useful to be able to easily set up a prefix to be used by
integrating the environment variables it exports.
Test Plan:
```
$ cat prefix.sh
export PATH=/home/apol/devel/kde5/bin:$PATH
export LD_LIBRARY_PATH=/home/apol/devel/kde5/lib64:$LD_LIBRARY_PATH
export XDG_DATA_DIRS=/home/apol/devel/kde5/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}
export XDG_CONFIG_DIRS=/home/apol/devel/kde5/etc/xdg:${XDG_CONFIG_DIRS:-/etc/xdg}
export QT_PLUGIN_PATH=/home/apol/devel/kde5/lib64/plugins:$QT_PLUGIN_PATH
export QML2_IMPORT_PATH=/home/apol/devel/kde5/lib64/qml:$QML2_IMPORT_PATH
```
Reviewers: #frameworks, sitter
Reviewed By: sitter
Subscribers: kfunk, bcooksley, ngraham, sitter, cgiboudeaux, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D9299
|
|
Summary:
when KDE_INSTALL_USE_QT_SYS_PATHS has been explicitely set,
qmake can be considered a required dependency, otherwise the
paths will not be known, which would be unexpected.
Also does the code calling query_qmake, besides the one testing
for the same install prefix, not handle the case of empty strings
being returned and then results in bogus behaviour.
Thus this patch makes code fail hard if query_qmake is expected
to yield a result, but no qmake executable is found.
Reviewers: #frameworks, ltoscano, rdieter, apol
Reviewed By: apol
Subscribers: #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D6772
|
|
Reviewers: #frameworks, apol
Reviewed By: apol
Subscribers: #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D6773
|
|
|
|
Summary:
Enables generation of QCH files during a normal build,
for documenting the public API of a library.
These macros are especially done with release builds in mind,
so distributed packages (like from Linux distributions) can
include QCH files matching the version of the library and will be
also automatically updated on new versions of the libary.
Next to that these macros also support linking between different
QCH files, so a subclass from another library for which there also
is a QCH file installed will be linked to the entry in that other
QCH file.
This inter-QCH linking is especially useful for libraries extending Qt,
where many of the used types are from Qt libraries. The macros
come with the needed information for Qt libraries prepared, so the
used Qt libraries just need to be listed in the LINK_QCHS argument
by target names, like Qt5Core_QCH or Qt5Widgets_QCH.
This should be a nice supplement to online services like api.kde.org,
like Qt's own QCH files are to doc.qt.io,
While QCH files from an abstract POV could be seen similar to code
libraries, being components with links to lookup symbols/entries in
other QCH files, so the rules and code should be done with similar
concepts, currently CMake's target system seems bound to executable
code creation. So things like "file(EXPORT ...)" could sadly not be
reused, as custom targets are not supported with that.
Thus a custom macro had to be created for now. Also could I not find
a way to use namespaces like KF5::, for more consistent target naming.
The patch also adds two variables to KDEInstallDirs.cmake for
controlling where the QCH (and respective doxygen tag files) are
installed. The QTQCHDIR variant allows to install QCH files for
Qt-extending libraries into the same folder where Qt's own QCH
files are, so Qt Assistant & other QCH viewer pick up them automatically
to add them to the default help file collection.
The QCHDIR variant would provide a neutral, but central installation
location. Neutral, as it never "pollutes" the Qt system dirs with files
possibly unrelated to Qt-based development (e.g. when simply using qthelp
tools for documentation), and central, to help with finding available QCH
files for manually adding/loading them into a viewer, given there is no
official way currently to register the availability of QCH files on
installing.
Open questions:
a) target system for exporting/importing done in a sane way?
Better name pattern for the QCH targets than xxx_QCH
(see the targets created for Qt, like Qt5Core_QCH)?
b) sharing metadata with kapidox
Initially I placed these macros into the kapidox module, as this seems the
logic place. And would match what kdoctools does for user manuals.
Just, that would create a build dependency on kapidox which complicates usage
a little. Having these macros in ECM delivers them with no extra effort
needed.
The data in metainfo.yaml is partially duplicated with the data feed into
the macros. How to deduplicate that is still open. Especially with the need
to not depend on external data sources like identify.kde.org.
Issues:
* doxygen versions before 1.8.13 are broken and miss to include some files
with generated QCH (https://bugzilla.gnome.org/show_bug.cgi?id=773693)
* Qt Assistant often only built with QTextBrowser, while doxygen uses lots
of HTML5 (incl. hardcoded JavaScript)
(https://bugzilla.gnome.org/show_bug.cgi?id=773715),
needs e.g. distributions to use QtWebKit to work, upcoming Qt versions
might soon also have QtWebEngine based help viewer
(https://codereview.qt-project.org/#/c/111559/)
* inter-QCH links do not work in KDevelop currently
(see https://bugs.kde.org/show_bug.cgi?id=372747) if installed as
separate QCH files
More details/background info at
https://frinring.wordpress.com/2016/09/27/adding-api-dox-generation-to-the-build-by-cmake-macros/
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D2854
|
|
REVIEW: 128780
|
|
|
|
Update preferred path of appstream data files to /usr/share/metainfo
Requires modern versions of appstream metadata generators.
FEATURE
REVIEW: 128174
|
|
Summary:
Instead of using "share" use "${BIN_INSTALL_DIR}/data" on Windows,
this is the location provided by QStandardPaths for GenericDataLocation
on Windows.
Reviewers: dfaure
Reviewed By: dfaure
Subscribers: kfunk
Differential Revision: https://phabricator.kde.org/D1873
|
|
Better wait a little until applying this change, since this might break
assumptions, and we don't know yet if all distros are using a recent enough
AppStream (Generator) release.
This reverts commit 4b7a90bfe7a3e2eb3ae83c946c182a79fabc51e3.
|
|
As per AppStream release 0.9.4
|
|
Make Qt and ECM-based projects use the same directory sctructure (i.e.
where plugins are, libs, etc.) by default. Otherwise it creates a tiny mess
that might be controlled but usually won't.
In the end, otherwise, people need to keep adapting their systems with
environment variables anyway. All distros end up setting always this
setting as ON, as well as brave developers who don't have separate prefixes
for Qt and KDE.
REVIEW: 127169
|
|
templates are very useful as teaching tool in order to make
a minimal application that uses a certain framework.
templates in the KAppTemplate repository will always get forgotten
(plus kapptemplate is not really necessary as they work in kdevelop as well)
An ideal situation would be frameworks having templates in their own repos
with templates of barebone apps using the main framework features.
In order to do that, the cmake stuff needed in order to correctly install
a template needs to be ported to a place avaiable to all frameworks
REVIEW:126185
|
|
REVIEW: 126414
|
|
|
|
BUG: 341683
FIXED-IN: 1.7.0
REVIEW: 121999
CHANGELOG: KDEInstallDirs: warn about mixing relative and absolute
installation paths on the command line
|
|
|
|
Cache variables such as CMAKE_INSTALL_BINDIR may be used by other
modules included from parallel parts of the tree, so we should not touch
them. We still override them in the runtime environment, but this will
not interfere with parallel subtrees of the project.
As part of this, the order of precedence of variables specified on the
command line is changed, so that KDE_INSTALL_* is considered first
(although it is still considered "undefined" in the documentation). This
means that if you only specify CMAKE_INSTALL_BINDIR, that will be used
by both KDEInstallDirs and GNUInstallDirs, but if you specify both that
and KDE_INSTALL_BINDIR, KDEInstallDirs will use KDE_INSTALL_BINDIR
instead. This is probably not too useful, but seems more useful than
any other arrangement.
BUG: 342717
REVIEW: 121982
|
|
|
|
A previous commit inadvertantly changed the KF5 include prefix to kf5
(uppercase to lowercase).
|
|
REVIEW: 121646
|
|
Creating variables whose names start with CMAKE_ is a bad idea for
modules distributed outside CMake itself. Since the module is called
KDEInstallDirs, having a KDE_INSTALL_ prefix for the variables is clear
and intuitive.
Both CMAKE_INSTALL_* variables and the older KDELibs4-compatible
variables are provided, unless KDE_INSTALL_DIRS_NO_DEPRECATED is set to
TRUE before the module is included. Even then, the CMAKE_INSTALL_*
variables provided by the GNUInstallDirs module will still be set and
understood (for compatibility with that module), unless
KDE_INSTALL_DIRS_NO_CMAKE_VARIABLES is set to TRUE.
REVIEW: 121646
|
|
When installing to /usr, we should use /etc for configuration. Using
/usr/etc does not make sense.
REVIEW: 120246
|
|
when running with the KDE_INSTALL_USE_QT_SYS_PATHS option allow QMLDIR in
KDEInstallDirs to follow whatever is defined by qmake
this change makes sure that qml plugins will end up in a default Qt path
when using the super special magic flag.
|
|
KDE modules cannot assume the normal ECM modules are in the CMake module
path, and CMAKE_INSTALL_IMPORTS_INSTALL_DIR / QTQUICKIMPORTSDIR was not
set correctly. Also, ECMQueryQmake.cmake used a deprecated CMake command
(exec_program).
|
|
Packagers and other interested folks should pass -DKDE_INSTALL_USE_QT_SYS_PATHS=ON
when building in order to install various files to the same dir as the Qt5 install
dirs.
CCMAIL: kde-packagers@kde.org
REVIEW: 119901
|
|
This way, on the Debian versions of these OSes, the library directory
can be a multiarch path.
|
|
REVIEW:118020
|
