-
Notifications
You must be signed in to change notification settings - Fork 101
Cumulative patchwork from my repo #89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cumulative patchwork from my repo #89
Conversation
* Parallel build * `make check` support * Fix `debug`/`release` builds
* Force C++11 * Disable annoying warnings for deprecated declarations * Add -Wpedantic and even -Werror for src, but relaxe some warnings * Code cleanup for less warnings
* Introduce UBSan into CI * Fix UB with incorrect alignment. This is a dirty hotfix in the rxx_allocator.
Remove unused code and redundant ctors
Missed this fix in #bc4aa1e
But really QT_NO_CAST_FROM_ASCII can help prevent incorrect behavior on non-Latin1 input
As discussed on other Pull Requests, long-term support releases of RHEL/CentOS/derivates and Ubuntu still provide (and support) Python 2.7 no matter that it is not supported by the Python people anymore. This also includes Python 3.6 which is provided by long-term support releases of Linux distributions. This means that Python 2.7 and 3.6 will be in active use for 5-10 years more. Not everyone can install their own Python nor use Anaconda/Conda as installing packages not supported by the OS vendor then voids the warranty and support contracts with the OS vendor. It's okay to use PythonQt not shipping from the vendor but if you introduce your own Python installation/version then the vendor will disavow any support for anything breaking as they will blame interference with the system version. Hence when building Qt apps using PythonQt, one is stuck with the compiler, Qt version, and Python version provided by the OS vendor until the extended-extended EOL of the Linux distribution. From the developer point of view, this also means that security/stability can be delegated to the OS vendor and the developer do not need to provide security patches and maintenance fixes for Python, Qt, etc which they would need to do if they ship their own versions. It is the OS vendor's responsibility to ensure Python 2.7 and 3.6 are working on their distribution and is security and maintenance patched during the entire long-term support window. |
1. Fix failed tests count report 2. Support exact Python version match, add `--embed` flag for 3.8+ only 3. Code cleanup +4. Use canonical way to add RPATH, on GNU/Linux the Makefile is the same for projects with the TEMPLATE=app, and no redundant link flags for TEMPLATE=lib
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks - this looks good to me now, though I would like somebody else to have another look.
* Add support for `pkg-config`. If PKGCONFIG is set, skip old-style lookup. Useful on GNU/Linux and on macOS GHA, when `python-config` returns incorrect linkage options with missing `-Ldirs` * Add macOS GHA CI
uses: actions/upload-artifact@v3 | ||
with: | ||
name: wrappers_macos${{ steps.versions.outputs.MACOS_VERSION_SHORT }}_qt${{ steps.versions.outputs.QT_VERSION_SHORT }} | ||
path: generated_cpp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that's cool, thanks! I tried to get a Mac build working, but I lack experience with Mac builds and couldn't get Python to correctly link. Now only a Windows build is missing...
@iakov - are you done here? If yes, I will wait a bit for somebody else to chime in, and merge, if nobody objects. |
Added last cleanup as was requested. I'm done. |
Thanks a lot! |
#ifdef _POSIX_C_SOURCE | ||
# undef _POSIX_C_SOURCE | ||
#endif | ||
|
||
#ifdef _POSIX_THREADS | ||
# undef _POSIX_THREADS | ||
#endif | ||
|
||
#ifdef _XOPEN_SOURCE | ||
# undef _XOPEN_SOURCE | ||
#endif | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iakov - we have a problem with this code, as it undefines _POSIX_THREADS, which leads to errors due to missing defines in pythread.h
. As far as I can see, _POSIX_THREADS
is not defined in Python.h
, it just is checked (in pythread.h
) to see if POSIX threads are defined. It think it is defined in pthread.h
or a related include. The same seems to be true for the other symbols.
I'm inclined to revert this specific change, though I may be misunderstanding something. Can you please elaborate on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll make a PR to revert this to discuss this.
- this has been introduced in MeVisLab#89 and breaks builds including "pythread.h"
- this has been introduced in MeVisLab#89 and breaks builds including "pythread.h"
make check
for testsmake check
support is enabled