-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Minimal fixes to make pygame bootstrap work with python2legacy #1587
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
Conversation
…f python2 We don't know if pygame will work for the new python2, for now we force to be build only for python2legacy because we know for sure that it works (we always can grant python2 compatibility later or not...this could be the first step to deprecate pygame bootstrap)
Because we will fix the pygame bootstrap build for python2legacy not for python2
…use of refactored distribution methods)
And: - remove hardcoded entries - add cflags to allow build with newer ndks - comment APP_STL line and set it to c++_static because the gnustl will be removed in android ndk 18, plus the default behaviour is to use the static stl lib...so...better let the android build decide depending on the ndk used.
Because with the latest changes in master branch we need an ndk with the `unified headers feature`...so...we expect to find an ndk > 15 (preferably ndk17c or ndk18b at the time of writing)...this will allow us to use the same ndk for all bootstrap builds, otherwise we should use an old ndk to build the pygame bootstrap
The ideal would be to move the apk build from ant to gradle...but this will require more work...for now we fix the java version problem we have with ant's build....because the other option it's far more complicated...maybe we will get there in future commits...
Update: this pr may fix the issue described in #1582 |
ndk_15_plus_patch = join(self.get_recipe_dir(), 'jpeg-ndk15-plus.patch') | ||
shprint(sh.patch, '-t', '-d', | ||
join(self.get_build_container_dir(arch), 'jpeg'), '-p1', | ||
'-i', ndk_15_plus_patch, _tail=10) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wondering why don't we apply the patch using the patches
attribute?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I remember...it's for the jpeg path, If we use the default patching method the file will not be found...but I'm thinking now that maybe we can add the needed levels to the patch, so we could refactor this into the default patching mechanism...I suppose that this should work...I will try to make some tests about that ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes that would be awesome, that would simplify the code a little bit 👍
Looking good to me. I'm just curious about why would you use Error was: |
The pygame bootstrap is not working with the latest changes in master branch:
So...saying that, this pr fixes all the mentioned issues and makes that the pygame bootstrap uses the refactored distribution methods (already in python recipe, no need to touch that).
This has been tested with ndk-r17c, ndk-api=19, android-api=27 and arch
armeabi-v7a
.This is a quick fix because still will be issues to solve...pyjnius is not working at runtime, despite it compiles/installs fine (pygame bootstrap uses the old
renpy
entries instead of thekivy
ones...).Build Note: because we still use ant build for pygame bootstrap, the path of the final apk is not the same as the ones used by other bootstraps (the others uses gradle)...so...buildozer may have troubles with that (I dont know that for sure...it's only my guess)
Note about pyjnius: I suspect that we can make pyjnius work by moving from ant to gradle (and move the relevant code from renpy folder to the kivy one)...but this is quite a work...I'm not sure if we should do that...
I know that has been some talks about removing pygame...maybe it's the time...but even if we do that...this code does not affect the core of the project... so I think that could be safely merged after the proper reviews/discussions because all the changes introduced in here only affects files needed by pygame/sdl...so...easy to remove later.