Conversation
See python/cpython#128161 "Defining iterator in a separate class no longer works in 3.13" We have iterator for SkTextBlob defined by SkTextBlob::Iter(textblob), which is the c++/pybind11 equivalent of the same situation. Following the suggestion: python/cpython#128161 (comment) Also see actions/runner-images#11241 Fixes skia-python#295
…o it earlier. See https://cibuildwheel.pypa.io/en/stable/options/#linux-image and pypa/cibuildwheel#1772 Fixes skia-python#284 and skia-python#175 The newer Linux has /usr/bin/ninja and does not have python
Comments about recovering from auditwheel repair changing the checksums to match current build
…L contexts with EGL There are two ways of enabling EGL support on Linux AFAIK: `skia_use_egl=true` switches over to X11 completely. Or we just add `GrGLInterfaces::MakeEGL` to GLX builds. This is the 2nd approach. `skia_use_egl=true` is simpler, but modifies existing X11 behavior. Fixes skia-python#287
gn is really written for clang. Later version of gn has this fixed, but won't build on older g++ (12) for another problem. Sigh. Staying in this version of gn for the main builds. Fedora ships gn actually, though it is a lot more change to adapt to this.
On EL7, EGL/egl.h is in mesa-libEGL-devel instead of libglvnd-devel (later Redhat) Missing GLES2/gl2.h - in mesa-libGLES-devel It is not likely that the runtime (libgGL*) libraries are missing if the devel are installed, but you never know. Include them also.
Move the EGL test before the others to avoid messing the others up
See pypa/cibuildwheel#2118 Excluding libEGL.so.1 is enough.
Native aarch64 linux CI hosts are fast enough. These workarounds are not needed anymore. Fixes skia-python#315
… available. 3.11/3.12/3.13 (and 3.14 dev) are apparently available via setup-python. Another attempt at skia-python#318
…40.0-231-g5b8860c391)
Native aarch64 linux CI hosts are fast enough. These workarounds are not needed anymore. Fixes skia-python#315 Conflicts: .github/workflows/ci.yml
|
Fedora / gnome / gtk4 is planning to go pure Wayland (without x11) in the next year or so. |
…--skip-unavailable option
|
Sure, adding EGL support would be perfectly fine. As for the dependency complication, we might just skip bundling |
|
@kyamagu the change in size in quite minimal. The inconvenient thing is that libEGL is needed but not bundled, so linux users need to install it separately, whether they use it or not. I just checked my system , Xorg and Xwayland both depend on it, so this is likely a non-issue. |
|
@kyamagu ready to go, I think, except needing a few more tests on the newer runtime effect stuff, and canvas.drawTextOnPath . As usual, read the new readme.m* first. Sorry a fair amount of CI / build stuff is temporary . |
|
Added 20 new tests covering the new code, too. |
|
@kyamagu Btw, I feel like having a v87 rc1 at this point too (if possible) - which adds windows arm64 support. Don't know how painful it is to do that yet - lack of native gn/ninja at the time, and older c++ code with newer compilers. The other stuff is the EGL change here: I have always said I don't want to add new functionality to v87, but it might be a good thing to keep the build machinery in sync one last time before we stop touching v87 completely. Anyway, I ll play with that a bit first on my repo as it is likely to be messy (lack of native gn/ninja & much newer compiler on old code). |
|
Hmm, I forgot v87 has some python 2 dependency too... |
kyamagu
left a comment
kyamagu
left a comment
There was a problem hiding this comment.
We should have the README updated to be explicit about the EGL dependency. Otherwise, it looks good to me.
|
@kyamagu the addition of native build and arm64 windows was quite smooth with v87 - tagged it as v87.9rc0 https://github.com/kyamagu/skia-python/releases/tag/v87.9rc0 (I think helped by the fact that arm64 windows can run x86_64 binary, so nothing needed on old gn / ninja, unlike the aarch64 linux case) - I am working on rc1 which is +EGL . That turns out to be the more troublesome part as upstream only started to allow glx and egl going side by side around m122/m123, so it requires a bit more source-code level backport from m122/m123 back to m87. Anyway, it is a relatively small change nonetheless - renaming the "non-default" GL interfaces to something else while binding to python in the m13x way. I'll tidy that up and bundle that up and tag it as v87.9rc1. I guess basically arm64 windows people can upgrade to v87.9rc0 or rc1, linux people who wants egl can upgrade to 87.9rc1 . In both case it is people who want extra opting in to rc's. Then we have between rc1 and 87.9 (I would rather call it 87.10 just to avoid thinking whether 87.9 is before or after 87.9 - I think you had use "post1" etc for afterwards?) to decide whether to withdraw egl support on 87.x proper, the last of v87. |
|
Regarding the m87 branch, semantic versioning follows the packaging guideline. Post-release is meant for a minor fix for the release pipeline, e.g., a CI error fix. In the current EGL support context, this should be a minor revision update; 87.9 or 87.10. |
2 participants
Nothing interesting happened upstream between m136 and m138. Inclusive of #321 and part of #314 (the part that does native aarch64 linux builds). However, a few large additions (#322 , #329 ) and a small one (#324) .
@kyamagu I'll pull all of those into here when the separate CIs finishes, and let you know after I add a README.m138 . How do you feel about EGL ? That pull has bit-rotten slightly, so it needs an update before merging, but looks like wayland is coming and EGL will replace GLX / X11 at some point.