Age | Commit message (Collapse) | Author |
|
The variable name was wrong, not much to see here.
|
|
|
|
Summary: Use a similar strategy as D14528 to find qm files.
Test Plan: Analitza parts of KAlgebra are translated too.
Reviewers: #frameworks, aacid
Reviewed By: aacid
Subscribers: svuorela, aacid, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14529
|
|
Summary: Only extract the the stl shared object without the rest of libraries.
Test Plan: Built gcompris
Reviewers: #frameworks, vkrause
Reviewed By: vkrause
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D15685
|
|
Summary: Use QT_NO_NARROWING_CONVERSIONS_IN_CONNECT as default flags
Reviewers: dfaure
Reviewed By: dfaure
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D15566
|
|
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
|
|
the time
Found while grepping for examples of foreach(... RANGE ...) for my
cmake training material ;-)
|
|
Found while grepping for examples of foreach(... RANGE ...) for my
cmake training material ;-)
|
|
|
|
|
|
This reverts commit 6684cb99bdf408fc491e547393dbd7aac4d151f2.
See https://phabricator.kde.org/D8256 for details
|
|
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
|
|
On Windows at least this is simply broken and leads to tests failing because plugins from other modules cannot be found at all.
Based on this it is likely that it is broken on other platforms as well, it's just being hidden there by other logic.
CCMAIL: kde-frameworks-devel@kde.org
|
|
When building on non-glibc Unix platforms, such as Solaris, NetBSD, and Linux/musl or Linux/uclibc, multiple components of KF5 fail to build. This is because -std=iso9899:1990 is specified (for strict C90 compliance) but _XOPEN_SOURCE is not defined, so none of the POSIX interfaces are exported. I have seen this reported in at least:
* kinit
* kscreenlocker
* plasma-workspace
The attached patch resolves this issue on all our build boxes; additionally, applying it to my glibc builder did not change the already working result.
BUG: 373175
Differential Revision: https://phabricator.kde.org/D8256
|
|
Reviewers: apol, alexeymin
Reviewed By: alexeymin
Subscribers: alexeymin, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D15084
|
|
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
|
|
|
|
Summary:
ECMPoQmTools will need to have the translations downloaded at configure time instead of on build time, otherwise it needs an awkward second configure.
To that end we introduce a KDE_L10N_SYNC_TRANSLATIONS variable that allows it to do so.
ECMPoTools will download the translations in the build directory, because cmake shouldn't touch the sources. Have it check the build directory too when the macro is called.
Test Plan: Built analitza translations.
Reviewers: #frameworks, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: cgiboudeaux, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14569
|
|
|
|
Summary: Just default to whichever is installed
Test Plan: Built kalgebra
Reviewers: #frameworks, vkrause
Reviewed By: vkrause
Subscribers: alexeymin, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14544
|
|
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14541
|
|
Summary:
We'd check if the variable's value is defined, which is wrong and prevented us
from properly initialising using these deprecated variables.
It would also ignore the value we're passing to the actually right variable when
using it.
Test Plan: Built kstars which needs -DCMAKE_ANDROID_API=24
Reviewers: #frameworks, vkrause
Reviewed By: vkrause
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14187
|
|
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:
Some projects such as marble do some operations with the APK directory
before building. This allows us the project to copy the apk directory
over to the build directory and do whatever it pleases.
Test Plan: Built Marble
Reviewers: #frameworks, vkrause
Reviewed By: vkrause
Subscribers: vkrause, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D13403
|
|
Summary:
QT_USE_FAST_OPERATOR_PLUS has been deprecated in Qt 4.8, in favour of
QT_USE_QSTRINGBUILDER. The latter also covers QByteArray.
Qt5 headers still supports QT_USE_FAST_OPERATOR_PLUS (at least 5.11.1),
as subset of QT_USE_QSTRINGBUILDER as it was introduced in Qt4.8,
but not as documented build flag.
Given QT_USE_QSTRINGBUILDER is set here and thus triggers anything that
QT_USE_FAST_OPERATOR_PLUS would trigger in Qt code, removing it should
clean up the macro from undocumented features and thus reduce confusion.
No non-Qt is known at least in KDE repos which checks this build flag
otherwise, so no regression should be expected here as well.
Reviewers: vkrause
Reviewed By: vkrause
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D13800
|
|
Reviewers: cgiboudeaux, apol
Reviewed By: cgiboudeaux, apol
Subscribers: apol, kde-frameworks-devel, kde-buildsystem, cgiboudeaux, dhaumann
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D10166
|
|
Summary:
Quite some C++-based projects do not use .h as header file extension, but
.hpp, .hxx or other variants. Making the header file extension configurable
enables to make use of ECMGenerateHeaders in such projects.
Test Plan:
The added unit test works, existing unit tests work as before.
Also using in project with .hpp files works.
Reviewers: apol
Reviewed By: apol
Subscribers: apol, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D13721
|
|
|
|
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: Add new variable ANDROID_EXTRA_LIBS, which can contain list of full paths to libs to include in resulting APK file. This can be used to include plugins that are not directly liked to executable, for example OpenSSL libs for QtNetwork SSL/HTTPS support.
Test Plan: Build project with -DANDROID_EXTRA_LIBS="/path/to/lib.so;/path/to/other_lib.so". Build without it. In both cases verify APK contents.
Reviewers: apol
Reviewed By: apol
Subscribers: kde-buildsystem, kde-frameworks-devel
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D13198
|
|
|
|
Otherwise androiddeployqt fails like it's failing now for kirigami
https://binary-factory.kde.org/view/Android/job/KirigamiGallery_android/48/console
|
|
Summary:
These typos show up in the generated manpages.
Reviewers: #frameworks, alexmerry, kossebau, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: cgiboudeaux, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D12867
|
|
|
|
|
|
|
|
Use the variable we just created to look up Qt5.
Remove debug warning.
|
|
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:
Refactor the apk-generating code into a separate function, in views of
eventually even make it a module.
It also changes so that if no APK dir is specified, a generic dummy one is
used. Useful for proofs of concept.
Test Plan: Built kate, got kate and kwrite apks
Reviewers: #frameworks, #build_system, vkrause
Reviewed By: vkrause
Subscribers: vkrause
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D12150
|
|
Summary:
Back in the KDE Edu sprint, we decided we need such a check, otherwise
you get rather frustrated when the application isn't started. A patch to
androiddeployqt was submitted but rejected by the maintainer.
https://codereview.qt-project.org/#/c/207941/
Test Plan: kate doesn't build if we don't pass Q_DECL_EXPORT, builds if we do.
Reviewers: #frameworks, #build_system, vkrause
Reviewed By: vkrause
Subscribers: vkrause, vatra, aacid
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D12120
|
|
concepts
Summary: Mark as deprecated the redundant variables and focus on the difference.
Reviewers: #build_system, #frameworks, vkrause
Reviewed By: vkrause
Subscribers: vkrause
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D11984
|
|
Summary:
Instead of having ad-hoc code for gcc, let CMake do its thing. It has a lot of
logic that we may be interested in, for example it will make the clang switch
much smoother.
Note it raises the minimum cmake to 3.7 for Android, which was released almost
2 years ago.
Test Plan: Built kalgebra on it using kdeorg/android-sdk
Reviewers: #frameworks, #build_system, vkrause
Reviewed By: vkrause
Subscribers: vkrause
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D11776
|
|
|