871
|
|
|
Christophe Giboudeau... |
|
5 years ago
|
|
|
870
|
|
|
Aleix Pol |
|
5 years ago
|
|
|
869
|
|
|
Pino Toscano |
|
5 years ago
|
|
|
868
|
|
|
René J.V. Bertin |
|
5 years ago
|
|
|
867
|
|
|
l10n daemon script |
|
5 years ago
|
|
|
866
|
|
|
Friedrich W. H. Koss... |
v5.52.0, v5.52.0-rc1 |
5 years ago
|
|
|
865
|
|
Bindings: Support using sys paths for python install directory
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
|
Stefan Brüns |
|
5 years ago
|
|
|
864
|
|
|
Stefan Brüns |
|
5 years ago
|
|
|
863
|
|
|
Harald Sitter |
|
5 years ago
|
|
|
862
|
|
|
l10n daemon script |
|
5 years ago
|
|
|
861
|
|
|
Adam Reichold |
|
5 years ago
|
|
|
860
|
|
|
Antonio Rojas |
|
5 years ago
|
|
|
859
|
|
|
Aleix Pol |
|
5 years ago
|
|
|
858
|
|
|
Aleix Pol |
|
5 years ago
|
|
|
857
|
|
|
Aleix Pol |
|
5 years ago
|
|
|
856
|
|
|
Aleix Pol |
|
5 years ago
|
|
|
855
|
|
|
Aleix Pol |
|
5 years ago
|
|
|
854
|
|
|
Laurent Montel |
|
5 years ago
|
|
|
853
|
|
|
Stefan Brüns |
|
5 years ago
|
|
|
852
|
|
Bindings: Correct handling of sources containing utf-8
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
|
Stefan Brüns |
|
5 years ago
|
|
|