Skip to content
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

Python 3.12 #167

Open
4 of 5 tasks
naveen521kk opened this issue Feb 16, 2024 · 5 comments
Open
4 of 5 tasks

Python 3.12 #167

naveen521kk opened this issue Feb 16, 2024 · 5 comments

Comments

@naveen521kk
Copy link
Member

naveen521kk commented Feb 16, 2024

This is going to be the tracker of things that are to be done.

Initial work done at: #165 - this builds successfully, though doesn't pass tests as setuptools doesn't directly support Mingw-w64 compilers.

Things to be done/discussed before deploying:

@MehdiChinoune
Copy link

MehdiChinoune commented Feb 19, 2024

My proposition about SOABI/EXT_SUFFIX to use a consitent naming so anyone could differentiate them according to their ABI, something like mingw_<cpu_arch>_<c_runtime>_<toolchain>
where:
cpu_arch = x86_64, aarch64 or i686 (or any new possible architecture)
c_runtime = msvcrt or ucrt
toolchain = gnu or llvm, the toolchain here means Compilers (gcc vs clang) + linkers (binutils vs LLVM tools) + c++ library (libstdc++ vs libc++) + OpenMP library (gomp vs llvm-openmp)

@MehdiChinoune
Copy link

Another proposition is to implement PEP668, like we discussed in discord.

@naveen521kk
Copy link
Member Author

Oh right, pep668, I'll add that to the list of things to do.

@lazka
Copy link
Member

lazka commented Jul 28, 2024

From what I understand the SOABI change and PEP668 are not blockers for the update and could in theory be handled afterwards, no?

@naveen521kk
Copy link
Member Author

From what I understand the SOABI change and PEP668 are not blockers for the update and could in theory be handled afterwards, no?

I think changing the SOABI after the update would be possible, though it should be before making python 3.12 the default one. For, PEP668 yeah it could be handled afterwards.

naveen521kk added a commit that referenced this issue Nov 2, 2024
Currently, the platform names are hardcoded in many places,
and are not named consistently. This commit fixes it by
standardizing the names to be returned by `sysconfig.get_platform`.
The naming is based on #167 (comment)

Similarly, `EXT_SUFFIX` is also standardized to be consistent with the platform names.

Signed-off-by: Naveen M K <[email protected]>
naveen521kk added a commit to naveen521kk/cpython that referenced this issue Nov 2, 2024
Currently, the platform names are hardcoded in many places,
and are not named consistently. This commit fixes it by
standardizing the names to be returned by `sysconfig.get_platform`.
The naming is based on msys2-contrib#167 (comment)

Similarly, `EXT_SUFFIX` is also standardized to be consistent with the platform names.

Signed-off-by: Naveen M K <[email protected]>
naveen521kk added a commit to naveen521kk/cpython that referenced this issue Nov 2, 2024
Currently, the platform names are hardcoded in many places,
and are not named consistently. This commit fixes it by
standardizing the names to be returned by `sysconfig.get_platform`.
The naming is based on msys2-contrib#167 (comment)

Similarly, `EXT_SUFFIX` is also standardized to be consistent with the platform names.

Signed-off-by: Naveen M K <[email protected]>
naveen521kk added a commit that referenced this issue Nov 2, 2024
Currently, the platform names are hardcoded in many places,
and are not named consistently. This commit fixes it by
standardizing the names to be returned by `sysconfig.get_platform`.
The naming is based on #167 (comment)

Similarly, `EXT_SUFFIX` is also standardized to be consistent with the platform names.

Signed-off-by: Naveen M K <[email protected]>
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

No branches or pull requests

3 participants