pygame recipe #2019
pygame recipe #2019
Conversation
robertpfeiffer
force-pushed
the
develop
branch
3 times, most recently
from
f863935
to
932c05a
Compare
robertpfeiffer
force-pushed
the
develop
branch
from
932c05a
to
a10cd13
Compare
|
Nice work, I'm pleased to see the recipe is pretty simple in the end!
In general we'd like to tag specific versions, but for something like this it's reasonable to have a moving target. I think the obvious options are:
I don't really mind which we do. I wouldn't normally like the last one, but good pygame support is a big target so it's reasonable to compromise for ease of use. |
There was a problem hiding this comment.
Looks like there are some merge conflicts, but since the assets stuff is being covered by the other PR I hope it should be straightforward to resolve.
The recipe looks good to me, happy to merge as soon as there are no conflicts (and probably let's merge the assets dir PR first to keep things simple).
One minor thing: could you add the pygame recipe to one of our CI tests? Seems worth testing that we don't break the build.
|
|
||
| def get_recipe_env(self, arch): | ||
| env = super(Pygame2Recipe, self).get_recipe_env(arch) | ||
| if 'sdl2' in self.ctx.recipe_build_order: |
There was a problem hiding this comment.
Won't this always be True, or in any case you always want to set the cross compile and android env vars?
| url = 'https://github.com/pygame/pygame/archive/android-2.0.0-dev7.tar.gz' | ||
|
|
||
| site_packages_name = 'pygame' | ||
| name = 'pygame2' |
There was a problem hiding this comment.
Are you going to officially make the new release pygame2, with e.g. a different name in pip? If so then fine, but if not it's probably more obvious to just call the recipe "pygame". Happy to go with your preference though.
| install_in_hostpython = False | ||
|
|
||
| def prebuild_arch(self, arch): | ||
| super(Pygame2Recipe, self).prebuild_arch(arch) |
There was a problem hiding this comment.
| super(Pygame2Recipe, self).prebuild_arch(arch) | |
| super().prebuild_arch(arch) |
|
Sorry for missing that one. This is also looking good to me. I think we could make it to the tree pretty easily by:
If you're busy I'd be happy to help out |
|
Looks good to me. The one failure looks like maybe a network issue, @AndreMiras do you know about it? |
|
Yes it's seems to be a network hiccups on the macOS build. I think we're covered by the other builds. I'll restart the failing build now. |
|
Looks like the test failure is due to a test target not existing. @AndreMiras is this due to a recent change? If it's something simple I'm can push the change and merge. |
|
Yes it's due to the recent changes. Basically it's still running on an old .travis.yml, but somehow it picked up the new Edit: ideally this is what I imagine the PR could look like #2164 I've started from your branch, squashed the commits, made a comprehensive commit message and rebased to upstream develop. I've also edited the |
| class Pygame2Recipe(CompiledComponentsPythonRecipe): | ||
|
|
||
| version = '2.0.0-dev7' | ||
| url = 'https://github.com/pygame/pygame/archive/android-2.0.0-dev7.tar.gz' |
There was a problem hiding this comment.
Usually the version should be configurable
| url = 'https://github.com/pygame/pygame/archive/android-2.0.0-dev7.tar.gz' | |
| url = 'https://github.com/pygame/pygame/archive/android-{version}.tar.gz' |
| open("Setup", "w").write(setup_file) | ||
|
|
||
| def get_recipe_env(self, arch): | ||
| env = super(Pygame2Recipe, self).get_recipe_env(arch) |
There was a problem hiding this comment.
Nitpicking
| env = super(Pygame2Recipe, self).get_recipe_env(arch) | |
| env = super().get_recipe_env(arch) |
|
Merged via #2164 thanks again |
As discussed on the Discord, this is a recipe to build apps based on SDL2-based pygame.
It currently references https://github.com/pygame/pygame/tree/android, a branch that will continue to live until we have an official stable release of pygame based on SDL2 with android support. Is that OK? Should recipes only refer to tarballs/tagged snapshots/releases, or is it allowed to have a moving target in there?
Simple examples have been tested by other pygame users (it doesn't just build on my own machine) but some pygame functionality is still untested, and some dependencies like freetype, postmidi and libjpeg are currently not part of the build. It's usable, but not complete.
Your feedback is appreciated.