Merged #2674 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2674#event-10561805696
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Nice, thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2674#issuecomment-1748632819
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing lis
I did that, and I also updated the version in the `INSTALL` file.
I didn't test this build config with all the Python versions, and I won't get
to that next week, but will do it the week of Oct 16. I find any issues, I can
open a fixup PR.
--
Reply to this email directly or view it on GitHub:
@encukou pushed 2 commits.
9c96b7882d7db454818c8ed8a9953e91b7b9ac15 Python stable ABI: Define
Py_TPFLAGS_IMMUTABLETYPE as no-op if missing
efdd3ede6c11938d0252f9125fabf6326b349614 Python Stable ABI: Build for Stable
ABI, require Python 3.7+
--
View it on GitHub:
https://github.com/rpm-softwa
I'd prefer the "Fix comment style" commit to be merged into the previous commit
that introduces the comment, but other than that looks fine to me. Unless you
have something else you're planning to work on here, just flag ready for review
and I'll merge, we already did the review part here.
--
@encukou pushed 2 commits.
6394b1d583a3dae612c49baa6ad28b8b555d410b Fix comment style
8343d71e5043713a38daf3436a7e489134421acf Python Stable ABI: Build for Stable
ABI, require Python 3.7+
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2674/files/1f41d7e4513b0f5c3dfb
The cmake nits aside, I briefly skimmed through this and seems like a lot of
fairly mechanical transformations (even saw a mention of coccinelle in there),
and nothing in the "OMG we can't do that" department.
So just trim out the extra complications from the cmake department and I'll be
happy
I think that's still unnecessarily complicated :sweat_smile:
In a case like this using cmake's integration doesn't help because it's only
*more* code and fu to support. I don't really want to see a single option
related to this because those are just extra baggage that can break and need
test
Would this work?
- CMake 3.26+ default:
- Build for stable ABI using CMake's mechanism
- Needs Python 3.7+
- Older CMake, and builds with `-DENABLE_PYTHON_SABI=OFF`:
- Needs Python 3.2+
- On Python 3.7+, build for stable ABI "manually" by defining
(I haven't tested, I'm still not sure
@encukou pushed 1 commit.
1f41d7e4513b0f5c3dfbd7f1f19e60774bd02b15 Select Python 3.7+ stable ABI
"manually" if CMake doesn't support it
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2674/files/ccc3af9c97ba635f8ef66aad4333c3ad0f617bcc..1f41d7e4513b0f5c3dfbd7f1f19e607
@encukou pushed 2 commits.
69db01e2c2a6321cd3df9b8b60c5fb9f407a039b Fix comment style
ccc3af9c97ba635f8ef66aad4333c3ad0f617bcc Select Python 3.7+ stable ABI
"manually" if CMake doesn't support it
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2674/files/1da65d26b64c
> Requiring Python >= 3.7 is not a problem, I'm just curious as to what makes
> that particular version special.
[`PySlice_GetIndicesEx`](https://docs.python.org/3/c-api/slice.html#c.PySlice_GetIndicesEx)
uses a deprecated implementation (on all Python versions) if ABI compatibility
with 3.6 is
See my earlier comment, I don't WANT it to fall back to current behavior
because then you never really know whether a patch is SABI compliant or not
because your setup *may* depend on these factors.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management
As it stands, we gracefully fall back to the current behavior anyway, so I
don't think the CMake stuff is a reason to hold up this PR.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2674#issuecomment-1740870818
You are receiving this bec
Nah. It ain't that hard really.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2674#issuecomment-1740851046
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm
Well, I guess then we should hope for [my CentOS Stream
MR](https://gitlab.com/redhat/centos-stream/rpms/cmake/-/merge_requests/11) to
be merged? 😅
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2674#issuecomment-1740838362
You are rec
I did look at the FindPython module, and to me that looks just the kind of
gibberish we left autotools behind for. No thanks. I'm fine importing it as
long as it's somebody elses headache but that's the end of that.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-so
@pmatilai I would just backport the FindPython module and conditionally use it
if CMake is too old.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2674#issuecomment-1740820797
You are receiving this because you are subscribed to this thr
I think, if we go for the stable ABI we should then stick to it too, meaning
simply cut off support for versions where not available.
Requiring Python >= 3.7 is not a problem, I'm just curious as to what makes
that particular version special. Cmake >= 3.26 is too new for us to require
though,
> With CMake 3.26+, stable ABI will be used by default.
This is fine, we can work in subsequent PRs to handle it internally for older
CMake versions.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2674#issuecomment-1738117094
You are re
These are the changes needed to use Python's stable ABI. This allows the
extension to be used without recompilation with multiple versions of Python
(from 3.7 until an ABI break).
Hack to make this easier:
- type objects are allocated when the module loads, stored in global pointers,
and never
21 matches
Mail list logo
