Proof of concept for Python 3 without CrystaX, plus API 27 support #1375
Conversation
|
Just to note, this PR will not actually work on its own, it depends on a python bundle that I packaged manually (you can see references to the filepath in my home directory in the PR). I'll probably make this automatic before moving on to a proper PR, just so people can test it if they want. |
|
Thanks a lot for sharing this! |
|
¡¡¡Those are great news!!! I also was working on a python 3 recipe for version 3.7 and I made very similar changes, plus some others (but without removing crystax). I successfully build the mentioned python 3 recipe, but it fails at run time when I put on my device...without a clear message to me... The mentioned python recipe supports the same libs than the python 2 recipe (plus some others). So...what is the current pr status? ...do you already managed to successfully build/run python3? I ask because I could share my progress via WIP pull request... but maybe there is no need for that... |
|
@opacam Did you see my files and instructions at https://github.com/inclement/crystax_python_builds ? They're what I used to build python3.6 with crystax, they may be helpful for 3.7. I'm working on implementing this python3 build in a proper way that fits better into p4a. I'll make a PR for it when it's usable. |
|
See #1412 for the PR I'm actually working on. At the time of writing it is at a very early, hacky stage, but posted so that interested parties can follow it. I'll close this one now in favour of the other. |
|
Ei @inclement, first of all, thanks for the link you send me sure it will be useful at some point. I think it's more interesting your approach in this pr using the standard sdk/ndk, so, yesterday I test it and I was unable to build the python recipe, here are a little report that may be helpful: The preparation of the test system:
So, saying that, all the stuff I put below affects mostly to the cpython used in the recipe (your git branch of cpython bpo-30386) not the p4a work. The first tests failed when compiling the python “native build”, when compiling zlib module: this I managed to fix by un-commenting the zlib line (line number 354 of Modules/Setup.dist). Then the native build succeed, but then failed when building the external libraries (ncurses). The libncurses are enforced to be build, no matter what, I think that his install are hardcoded somewhere inside some of the build scripts (take a look around line 29 of file Android/makesetup: function "list_ext_libraries")...sorry I don't find where is harcoded, but I cant take a deep look... Ok, hope that this could be useful. I suspect that the cpython's branch bpo-30386 may need some slight modifications to match our needs... If you want I can take a look and try to find where the hell are enforced to be build the ncurses library, I've forked your cpython branch so if you are interested I could make some changes into a new branch. Ok, thats all, if you need some help just tell me, no problem ;) Note: I wrote here instead of the new pr because we started this here, and all the tests done are based on this, I will try to test with the new changes and keep you posted at the new pr. |
As I remember, this is one of a few different changes I made to get bpo-30386 to work with api 27. I didn't commit them here as I made them in a hacky way.
It isn't hardcoded, in the sense that you can pass different arguments to makesetup in order to make it not add them. You can also edit the Makefile to remove the WITH_NCURSES line. This doesn't really matter as my implementation in the new PR just doesn't include these unnecessary parts.
I think this would be best, this PR is not intended to be a good way to do things, just a proof of concept. #1412 should actually work, or at least move towards working. |
This PR is most of the work necessary to let p4a build and use Python 3 with the normal Google NDK, using the build process submitted to CPython at python/cpython#1629 (bpo-30386).
This isn't intended for merging: it's super hacky and mostly just a test to see if it could work, plus I'm not sure if the PR I'm using is the most up to date. However, it does work, and I'll now move to fix up a proper version. Even in the worst case that these types of changes never get updated or land in Python, it's more than enough to support p4a in the foreseeable future, and already far more understandable than the old hacky Python 2 method.
I also got this working with API 27 for good measure. This involved a few further hacks to the Python build, which aren't yet in this PR, but shouldn't be important for other recipes. As far as I can tell that worked okay, if I upload the APK to the Play store it doesn't give a warning about the API version so it seems happy with what I did. The important thing here is: the target SDK version must be 27 or higher, the compile SDK version may be lower than that (but doesn't really matter right now), the min SDK version must be at least 21 for this Python version (I think), and finally the NDK target version controlled by APP_PLATFORM must have a low value, ideally equal to the min SDK. This NDK setting is not currently controlled by python-for-android, which I now realise is an omission that probably led to a range of build issues for different people.
I know various people have been interested in aspects of this, please let me know if you have any questions. I'll update this if I achieve anything interesting, and also fix up all the work to properly add the features.