| Age | Commit message (Collapse) | Author |
|---|
|
Summary: Change transport protocol from http to https
Reviewers: apol, cgiboudeaux
Reviewed By: apol, cgiboudeaux
Subscribers: cgiboudeaux, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D25753
|
|
Summary: Correct spelling in extra-cmake-modules comments.
Reviewers: apol
Reviewed By: apol
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D25752
|
|
When using the Emscripten toolchain, there is no library linkage
necessary (there is no library) and the system include search paths
provide EGL headers.
Reviewed By: vkrause
Differential Revision: https://phabricator.kde.org/D24182
|
|
|
|
Summary: Instead of passing the data from stdin, pass the path, this way if there's an error wayland-scanner will be able to tell us the file and line where it's failing.
Test Plan: Built kwayland and kwin with it
Reviewers: #kwin, #frameworks, zzag
Reviewed By: #kwin, zzag
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D20105
|
|
Summary:
This one is originally coming from Solid, but there are several more copies
in our repositories (plasma-desktop, kwin, powerdevil, etc).
Reviewers: cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: cgiboudeaux, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D19486
|
|
GIT_SILENT
|
|
Summary:
I don't understand where plasma-desktop actually finds that old find
module, but this fixes the build at least.
Reviewers: cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D19499
|
|
Summary: Originally coming from KWin, but now also needed by qtbase.
Reviewers: cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: kossebau, apol, cgiboudeaux, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D18943
|
|
|
|
Summary:
${EGL_INCLUDE_DIR} is the path up to 'egl.h' -- so the header is
${EGL_INCLUDE_DIR}/egl.h
The compile test on the other hand includes 'EGL/egl.h', so the path
that needs to be passed to the compile test is "${EGL_INCLUDE_DIR}/..".
Reviewers: #automotive, hausmann, #freebsd, apol
Reviewed By: #automotive, hausmann, apol
Subscribers: bcooksley, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D19075
|
|
Summary:
used by:
- knotification
- (possibly also knotifyconfig at some point)
- plasma-pa
- kmix
Reviewers: cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: aacid, apol, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D18952
|
|
Perform additional sanity checking by doing a compile test.
Differential Revision: https://phabricator.kde.org/D18960
|
|
Summary:
Avoids to have manually set the property on the generated source file to
deal with changed CMake policy CMP0071.
Reviewers: #frameworks, pino, apol
Reviewed By: apol
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D18088
|
|
Test Plan: kcoreaddons compiles again
Reviewers: lbeltrame
Reviewed By: lbeltrame
Subscribers: cgiboudeaux, skelly, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D18345
|
|
|
|
|
|
|
|
Summary:
This is currently in use by plasma-phone-components, but will also be
needed by KItinerary.
Reviewers: #build_system, #frameworks, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: cgiboudeaux, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D16954
|
|
New users can use this module instead of adding a copy of the old FindExiv2.cmake module.
|
|
According to lxr, we have 8 copies of this module in different repositories (+kdelib4support and a playground repo).
|
|
Summary:
The Qt5Help CMake modules contain the Qt5::qhelpgenerator target, so
look for that instead of Qt5Core. Otherwise, the Qt5::qhelpgenerator
is available only if Qt5Help was searched previously (which does not
happen often).
Using the Qt5::qhelpgenerator is more reliable than the search for the
qhelpgenerator executable based on the qmake path.
Test Plan:
build some framework with -DBUILD_QCH=ON, and notice that
the right path of qhelpgenerator is found directly with the
Qt5::qhelpgenerator target.
Reviewers: kossebau
Reviewed By: kossebau
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D16938
|
|
Summary:
The correct install directory is distro and arch specific, and should
match the configuration of the python installation the binding is
generated for. These directories can be queried using pythons
distutils.sysconfig.
When determining the install directory, it mimics the logic from
KDE_INSTALL_USE_QT_SYS_PATHS. When the python PREFIX is the same
as CMAKE_INSTALL_PREFIX, it defaults to using the path from
distutils.sysconfig, otherwise it keeps the current scheme, installing
below CMAKE_INSTALL_PREFIX.
The default behaviour can be changed by setting KDE_INSTALL_PYTHON{2,3}DIR
or by switching KDE_INSTALL_USE_PYTHON{2,3}_SYS_PATH ON or OFF.
Test Plan:
On a distro where sitearch is not below /usr/lib/pythonM.m/, but
/usr/lib64/pythonM.m/ (e.g. RH, SUSE 64bit), try to do:
cmake ..; make; install
Without the patch, the binding are installed into the wrong directory,
afterwards the correct path is used.
This should also yield the correct path on Debian and derivatives,
where dist-packages instead of site-packages is used (untested).
other test cases:
Keep current scheme: `cmake -DCMAKE_INSTALL_PREFIX=/opt ..`
Default to sys path: `cmake -DCMAKE_INSTALL_PREFIX=/usr ..`
Force sys path: `cmake -DCMAKE_INSTALL_PREFIX=/opt -DKDE_INSTALL_USE_PYTHON3_SYS_PATHS=ON ..`
Reviewers: #frameworks
Subscribers: bcooksley, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D15070
|
|
Summary:
The option is no longer used from any framework, and was always defaulting
to site-packages previously, as INSTALL_DIR_SUFFIX was empty.
Also see D15558, D15845.
Test Plan: build e.g kcoreaddons
Reviewers: #frameworks, apol, lbeltrame
Reviewed By: lbeltrame
Subscribers: lbeltrame, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D15867
|
|
PyQt>=5.11 is compiled with the 'PyQt5.sip' sipname by default. This causes a sipname mismatch with KF5 bindings and prevents them from loading:
To fix this, we compile KF5 bindings using the same sip flags (name and tags) that PyQt was compiled with. This ensures that we always use the correct sip name. We also stop setting the sip tags in FindPythonModuleGeneration.cmake to avoid duplication, and remove a (seemingly) unnecessary check for the Qt version that was forcing PyQt to be rebuilt for every patch Qt update.
Differential Revision: https://phabricator.kde.org/D15091
|
|
Summary:
Use of positional arguments is error prone, as e.g. switching order
of NAMESPACE and MODULENAME wont have the desired effect, as
the keywords are ignored for the first three arguments.
Parse all arguments with cmake_parse_arguments, and fix the documentation
(list supported arguments) and example (add TARGET keyword).
Test Plan: build bindings
Reviewers: #frameworks, dfaure
Reviewed By: dfaure
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D15559
|
|
Summary:
Depending on the locale, python3 may try to decode the source as ASCII
when the file is opened in text mode. This will fail as soon as the
code contains utf-8, e.g. (c) symbols.
While it is possible to specify the encoding when reading the file,
this is bad for several reasons:
- only a very small part of the source is processed via _read_source,
no need to decode the complete source and store it as string objects
- the clang Cursor.extent.{start,end}.column refers to bytes, not
multibyte characters.
While python2 processes utf-8 containing sources without error messages,
wrong extent borders are also an issue.
The practical impact is low, as the issue only manifests if there is a
multibyte character in front of *and* on the same line as the read token.
Test Plan:
Python3: Build any bindings which contains sources with non-ASCII codepoints,
e.g. kcoreaddons. Unpatched version fails when using e.g. LANG=C.
Python2: Both versions generate sources successfully.
Bytes vs characters test:
```
#define Q_SLOTS
class foo {
/* a */ public Q_SLOTS:
/* ä */ public Q_SLOTS:
};
```
`sip_generator.py --flags "" /usr/lib64/libclang.so Qt5Ruleset.py test.h out.sip`
Obviously, both lines should result in the same code, the unfixed version generates `public Q_SLOTS:` vs `public:`.
Reviewers: #frameworks, lbeltrame
Reviewed By: lbeltrame
Subscribers: lbeltrame, bcooksley, jtamate, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D15068
|
|
|
|
Summary:
The generated C++ sources include <sip.h>, so it must be available.
Check for it in the version specific directories and fall back to
the default include directories.
Test Plan:
install python2-devel and python3-devel
install one of python{x}-sip-devel
bindings should be generated for the matching python version.
Reviewers: #frameworks, arojas
Reviewed By: arojas
Subscribers: arojas, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14915
|
|
Summary:
In case both python 2.7 and 3 are installed, but clang python bindings
are only installed for python 3, there will be no error message but
the self check will fail.
Check for clang bindings for both python2 and python3 (if installed),
and use the first one found to generate the sip bindings files.
Note, it is possible to e.g. use python2 to generate the sip binding
files (requires clang bindings), but generate bindings for python
2, 3, or both (requires matching python-devel and python-sip-devel
packages).
Test Plan:
install python3-clang bindings
install python2-clang bindings
or one of the above
the matching python version is used to run sip_generator.py
Reviewers: #frameworks, arojas
Reviewed By: arojas
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14914
|
|
Summary:
iteritems is no longer an available method for dict in Python 3. Using
dict.items() is functionally identical, although it creates some overhead
for Python 2.7 (creation of a temporary list). As this is only called
when tracing, this is not a big issue. For Python 3, there is no
overhead (dict.items() returns an iterator).
Test Plan:
Run python3 sip_generator.py ...
Run python2 sip_generator.py ...
Both generate the same code
Reviewers: #frameworks, arojas
Reviewed By: arojas
Subscribers: arojas, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14912
|
|
Summary:
Keep the enum intact by emitting the class keyword in case the enum is
scoped.
Use the complete enum scope for parameter values, the enclosing scope is
only correct to use for unscoped enums.
The python Cursor.is_scoped_enum() method has been added with LLVM/Clang
version 5.0.
BUG: 397154
Test Plan: build kcoreaddons
Reviewers: #frameworks, mpyne
Reviewed By: mpyne
Subscribers: mpyne, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14908
|
|
Summary:
The canonical name is libclang.so, which seems to be available on all
distributions (RH, SUSE, Ubuntu, Debian, ...) while the symlinks with
version suffix (e.g. libclang-6.0) are specific to Debian and derivatives.
Keep the current checks, but fallback to the unversioned library name.
Test Plan:
on openSUSE TW/Leap:
run cmake
-> libclang is found
Reviewers: #frameworks, dfaure
Reviewed By: dfaure
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14909
|
|
These changes are not available in ECM 5.48.0.
|
|
Summary:
- Add support for SIDEBAR_ICONS on macOS
- Allow specifying a basename for the icon file via OUTFILE_BASENAME
- Add support for HiRes icons on Windows via icotool
I'm sorry this went all into one big change. I see that it's not optimal,
but it's really hard to rip it apart...
Also to me the whole code with support for two flavors of png2ico and icotool seems very spaghetti-ish. IMHO there's no good reason to keep supporting all three, icotool is the only maintained project and the only one supporting more than 128px wide icons. That's why I would suggest to simplify the whole code by only supporting icotool in one of the next releases.
Test Plan:
We use this version of ECMAddAppIconMacro in ownCloud client and it works...
I tested icotool natively and while cross-compiling on linux.
SIDEBAR_ICONS are also working...
If you want to test this with the ownCloud client, it's best to use
https://github.com/dschmidt/owncloud-client/tree/fix-app-icon-macro
because that contains a small fix I just PR'ed and which is not
in master yet. (We maintain a fork of the module there, so compiling it for Windows or macOS will automatically use the version of the module that I'm submitting)
Reviewers: vonreth, vpinon, apol, alexmerry, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: cgiboudeaux, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D13698
|
|
|
|
|
|
Summary: Instead of hardcoded /usr/lib, same solution as in D9116
Test Plan: Works fine with kwayland 5.42.0.
Reviewers: #frameworks, #build_system, cgiboudeaux
Reviewed By: cgiboudeaux
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D10201
|
|
Summary: This is copied from KScreenlocker, but will be utilized in Baloo too.
Test Plan:
- Autotests are working
- KScreenlocker and Baloo build with seccomp enabled
Reviewers: graesslin, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: cgiboudeaux, #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D8998
|
|
Summary:
Commit ee5b036c1df4776a258c0d8067fd2eaf18875829 added a new FindPulseAudio module with a slightly different syntax than the old one. Since the old module was removed with commit 7574022825804db2274bba992d6fc4a4817c1536 plasma-desktop and plasma-pa are broken. Just adding the old syntax as synonym for fixing this.
See also https://bugs.kde.org/show_bug.cgi?id=386659
Test Plan: compile tested with plasma-desktop
Reviewers: #frameworks, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: jriddell, ngraham, rikmills, cgiboudeaux, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D8777
|
|
Summary:
We have copies of this module in several PIM repositories (kdepim-runtime,
kldap, kimap, libksieve...).
It's time to move it to ECM and get rid of these copies.
Reviewers: #kde_pim, vkrause
Reviewed By: #kde_pim, vkrause
Subscribers: #frameworks, #build_system
Tags: #frameworks, #build_system, #kde_pim
Differential Revision: https://phabricator.kde.org/D8790
|
|
Will initially be used by KMix.
Differential Revision: https://phabricator.kde.org/D7823
|
|
Explicitely set LIBRARY_OUTPUT_DIRECTORY for the python module
Differential Revision: https://phabricator.kde.org/D7677
CCMAIL: release-team@kde.org
|
|
Summary:
Passing NO_DEFAULT_PATH ignores $PATH and ensures that we use the
previously-detected Qt5 binary path.
Test Plan:
qhelpgenerator is now picked up from the same location as Qt5::qmake. Before,
anything in $PATH was preferred even if it was the Qt 4 version.
Reviewers: #frameworks, kossebau, kfunk
Reviewed By: kossebau, kfunk
Subscribers: alexeymin, asturmlechner, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D6249
|
|
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
|
|
Summary:
Add a simple module to look for GNU gperf at build time, providing an
helper macro for adding generations to a list of sources.
gperf will be used to generate the C/C++ sources at build time, instead
of using static versions in VCS; at least kcodecs, khtml, and kio-extras
will be switched to this method.
Reviewers: #windows, #frameworks, #build_system, kde-mac, adridg, rjvbb
Reviewed By: adridg, rjvbb
Subscribers: kfunk, rjvbb, adridg
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D3830
|
|
Summary:
While my distro does have a versioned clang executable, it doesn't
have a versioned clang++ executable. The versioned executable is
still searched first, falling back to the unversioned one.
Reviewers: #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5291
|
|
Summary:
On Linux, inotify always exists; all you need is the header file.
On the BSDs, inotify is provided through a shim to kqueue, which
must be installed separately. Add a FindInotify to help sort
that out.
Based on RB 129316 and RB 129549.
Test Plan:
- On FreeBSD, reliably detects presence of libinotify in $LOCALBASE,
- Needs testing on Linux that it does find the header file.
Reviewers: apol, arrowdodger, #build_system, #frameworks, tcberner, ervin, skelly, dfaure, kfunk
Reviewed By: tcberner, kfunk
Subscribers: kfunk, #freebsd
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D3826
|
|
With some combination of PyQt/compiler this breaks the build of
kcoreaddons.
This reverts commit 2e20aeab6e86670a66ff99a7b79120c4004b4d22.
|
|
This should have been removed in a prior commit.
|
