Skip to content

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

Merged
merged 11 commits into from
Jan 30, 2023

Conversation

iakov
Copy link
Contributor

@iakov iakov commented Jan 21, 2023

  • Multiple improvements and fixes for QMake build system (parallel build, shadow build, make check for tests
  • Unit-test in CI after make check support is enabled
  • Undefined behavior fixed + UBSan in CI
  • Some memory leaks fixed
  • More build warnings and corresponding code cleanup
  • Add macOS GHA CI

iakov added 7 commits January 21, 2023 18:28
* 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
@he-hesce
Copy link
Contributor

he-hesce commented Jan 23, 2023

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
Copy link
Contributor

@mrbean-bremen mrbean-bremen left a 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.

iakov added 2 commits January 25, 2023 21:34
* 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
Copy link
Contributor

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...

@mrbean-bremen
Copy link
Contributor

@iakov - are you done here? If yes, I will wait a bit for somebody else to chime in, and merge, if nobody objects.

@iakov
Copy link
Contributor Author

iakov commented Jan 30, 2023

Added last cleanup as was requested. I'm done.

@mrbean-bremen
Copy link
Contributor

Thanks a lot!

@mrbean-bremen mrbean-bremen merged commit 1e794e5 into MeVisLab:master Jan 30, 2023
Comment on lines +37 to +48
#ifdef _POSIX_C_SOURCE
# undef _POSIX_C_SOURCE
#endif

#ifdef _POSIX_THREADS
# undef _POSIX_THREADS
#endif

#ifdef _XOPEN_SOURCE
# undef _XOPEN_SOURCE
#endif

Copy link
Contributor

@mrbean-bremen mrbean-bremen May 24, 2023

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?

Copy link
Contributor

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.

mrbean-bremen added a commit to mrbean-bremen/pythonqt that referenced this pull request May 24, 2023
- this has been introduced in MeVisLab#89 and breaks builds including "pythread.h"
mrbean-bremen added a commit to mrbean-bremen/pythonqt that referenced this pull request Jul 7, 2023
- this has been introduced in MeVisLab#89 and breaks builds including "pythread.h"
mrbean-bremen added a commit that referenced this pull request Jul 8, 2023
- this has been introduced in #89 and breaks builds including "pythread.h"
- fixes #103
@iakov iakov deleted the pr/cumulative_patchwork branch October 12, 2023 14:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants