-
Notifications
You must be signed in to change notification settings - Fork 152
Upgrade3.10.0 #281
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
Upgrade3.10.0 #281
Conversation
* Rename "Modules/random.c" to "Modules/bootstrap_hash.c" See python/cpython@6b4be19 bpo-22257: Small changes for PEP 432. (#1728) PEP 432 specifies a number of large changes to interpreter startup code, including exposing a cleaner C-API. The major changes depend on a number of smaller changes. This patch includes all those smaller changes. * Remove bundled copy of libffi (Closes #27979) See python/cpython@f40d4dd An installed copy of libffi is now required for building _ctypes on any platform but OSX and Windows.
Since python/cpython@f40d4ddff (Closes python/cpython#27979: Remove bundled copy of libffi), external version of libffi is required on linux.
manual method using python interpreter was not kept up
Since python 3.10 there are no more .def files see python/cpython@2c6e4e9 so I removed the cmake targets that used those and I suspect that one of them was force generating python3.lib They are using the #pragma and other directives to build the .libs automatically and for some reason the python3.lib is not built from the |
Python 3.10 dropped the Thank you |
I've managed to build libffi with cmake and manually add a reference to ctypes using this branch: I've successfully bootstrapped pip with ensurepip Now there are some problems with the other python targets inside the slicer python build that I am addressing right now. |
c225ac8
to
06c7e63
Compare
Ok, this commit solved an issue with limited libs. The build is working for 3.10 from this branch. The question that remains is about libffi. I am mentioning it because ctypes depends on libffi and I believe something should be done for the case of this line I believe it should be ok to inlcude such a stable and small lib inside the build system. Or at least give the developer an option to build it with this project or use the external one. |
@lassoan Turns out the hack I've deleted from the 3.9.8 branch was not needed after all. I've reverted it with 81cbdd1 On python 3.10 there are no more .def files so python3.dll is generated solely based on python3dll.c, which changed a bit from python39. The catch was a compile warning that I did not pay attention to, it was saying that it expected a ")" but found PYTHON_DLL_NAME. Simply defining it as I did in 4b8db2d solves the issue and generates the python.lib and python3.dll correctly. This current branch is working for 3.10 and should make it easier to transition to 3.10 when the time comes. |
Closing. Support for Python 3.10 was added through the following pull request: |
I am trying to add the support for python 3.10.0
I did some work based on @dand-oss branch https://github.com/dand-oss/python-cmake-buildsystem/tree/3.9.0
Reached this issue via Slicer/Slicer#5014
I am not sure if what I did can be merged but it is compiling with an error on xxlimited. I don't really know what it is and what it does.
I hope to help with this initial effort and get it working with python 3.10 soon.