D15070: Bindings: Query the install directory from python

bruns added a comment. In D15070#318493 , @bcooksley wrote: > We could, however that would not help people installing it as a regular user, rather than as root. > If I run this right now, as an unprivileged user, I get the following path

D15070: Bindings: Query the install directory from python

bcooksley added a comment. We could, however that would not help people installing it as a regular user, rather than as root. If I run this right now, as an unprivileged user, I get the following path returned: >>> sysconfig.get_python_lib( plat_specific=True,standard_lib=False )

D15070: Bindings: Query the install directory from python

bruns added a comment. If you can change PYTHONPATH for execution, why can't you specify GPB_PYTHONx_SITEARCH? I would expect if I do not specify a path manually, it should be installed in the default location. This btw. **does** honor PREFIX/EXEC_PREFIX, see

D8256: Add _XOPEN_SOURCE to C definitions

bcooksley added subscribers: FreeBSD, bcooksley. bcooksley added a comment. This change appears to have resulted in a severe regression of builds on FreeBSD. Any ideas? REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D8256 To: awilcox, alexmerry,

D15070: Bindings: Query the install directory from python

bruns added a comment. @bcooksley Of course I can not guarantee it does not break CI, but as long as it follows generic python standards and rules (i.e. properly setup distutils) it should work. On the other hand, I can guarantee it currently is broken for a number of distributions.

D14915: Bindings: Check if bindings can be generated for a specific python version

This revision was automatically updated to reflect the committed changes. Closed by commit R240:4275cfc3f75d: Bindings: Check if bindings can be generated for a specific python version (authored by bruns). REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE

D14914: Bindings: Use python version matching the found clang python module

This revision was automatically updated to reflect the committed changes. Closed by commit R240:451bc7609c2d: Bindings: Use python version matching the found clang python module (authored by bruns). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D14914?vs=39951=40794#toc REPOSITORY

D14912: Bindings: Make generator forward compatible with Python 3

This revision was automatically updated to reflect the committed changes. Closed by commit R240:b6e4e645dac6: Bindings: Make generator forward compatible with Python 3 (authored by bruns). REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE

D11776: Make use of upstream CMake infrastructure to detect the compiler toolchain

Martchus added a comment. @vkrause Thanks for confirming this. So it is not a local issue. Could you find a workaround (beside reverting these changes)? As I already mentioned, I'm not so familiar. However, for me the way CMake populates `CMAKE_CXX_STANDARD_LIBRARIES` doesn't look

D11776: Make use of upstream CMake infrastructure to detect the compiler toolchain

vkrause added a comment. It's the same issue I have here, but after our discussion at Akademy I assumed this to be local setup issue. Similar versions here, on Tumbleweed. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D11776 To: apol, #frameworks,

D11776: Make use of upstream CMake infrastructure to detect the compiler toolchain

Martchus added a comment. @apol I'm not that familiar with Android, but I guess the variable `CMAKE_CXX_STANDARD_LIBRARIES` is not limited to contain only a single library (note the plural in the variable name). So I think we should handle that. BTW, I'm just testing with the

D11776: Make use of upstream CMake infrastructure to detect the compiler toolchain

apol added a comment. @Martchus sounds like your CMAKE_CXX_STANDARD_LIBRARIES gets initialized wrong somehow, no? REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D11776 To: apol, #frameworks, #build_system, vkrause Cc: kde-frameworks-devel,

D14915: Bindings: Check if bindings can be generated for a specific python version

arojas accepted this revision. This revision is now accepted and ready to land. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D14915 To: bruns, #frameworks, arojas Cc: arojas, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D14914: Bindings: Use python version matching the found clang python module

arojas accepted this revision. This revision is now accepted and ready to land. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D14914 To: bruns, #frameworks, arojas Cc: kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D14912: Bindings: Make generator forward compatible with Python 3

arojas accepted this revision. This revision is now accepted and ready to land. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D14912 To: bruns, #frameworks, arojas Cc: arojas, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D11776: Make use of upstream CMake infrastructure to detect the compiler toolchain

Martchus added a comment. Herald added subscribers: kde-buildsystem, kde-frameworks-devel. This change produces invalid JSON in my setup: "stdcpp-path":" "/opt/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/libs/arm64-v8a/libgnustl_shared.so" -nodefaultlibs -lgcc -lc -lm -ldl", So

D14912: Bindings: Make generator forward compatible with Python 3

bruns added a comment. So, tested on Arch, openSUSE TW and Leap 15.0 ... @arojas - can you accept, also for the two other reviews? REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D14912 To: bruns, #frameworks Cc: arojas, kde-frameworks-devel,

Re: ECM Behaviour: Setting QT_PLUGIN_PATH on Windows

On Tue, Aug 28, 2018 at 10:35 PM Ben Cooksley wrote: > > Hi all, Hi all, > > We currently have a severe bug in ECM's AddTest macro due to it's > behaviour around the setting of QT_PLUGIN_PATH. On Windows it would > appear that the code in ECMAddTest mangles the environment variable, > removing

D8256: Add _XOPEN_SOURCE to C definitions

This revision was automatically updated to reflect the committed changes. Closed by commit R240:6684cb99bdf4: Add _XOPEN_SOURCE to C definitions (authored by awilcox, committed by dfaure). REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE

D8256: Add _XOPEN_SOURCE to C definitions

dfaure added a comment. Ah, found it in bugzilla :-) REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D8256 To: awilcox, alexmerry, dfaure Cc: kde-frameworks-devel, kde-buildsystem, mpyne, dfaure, michaelh, ngraham, bruns

D8256: Add _XOPEN_SOURCE to C definitions

dfaure added a comment. Let's push this then ;) You don't seem to have a developer account? I can push this but I need your email address for the git authorship. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D8256 To: awilcox, alexmerry, dfaure