[python-skia-pathops] Build from source, don't use wheel

[micwoj92]

Let’s just say trying to build skia from source (while following Arch package guidelines) is shit. ;)
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=python-skia-pathops#n20
I took skia-git PKGBUILD and modified it to output shared library, this also results in not building examples but I don’t need these anyway for this python package:

@@ -51,7 +52,7 @@ prepare() {
     # generate the ninja build files using gn
     cd skia
     tools/git-sync-deps
-    gn gen out/Debug
+    gn gen out/Debug --args='is_official_build=true is_component_build=true'
 }
 
 build() {
@@ -68,31 +69,15 @@ package_skia-git() {
     install -D -m644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
 
     # Static library
-    install -D -m644 out/Debug/libskia.a "$pkgdir/usr/lib/libskia.a"
+    install -D -m644 out/Debug/libskia.so "$pkgdir/usr/lib/libskia.so"
 
     # Headers
     find include $cxxfindheaders \
         -exec install -v -D -m644 {} "$pkgdir/usr/include/skia/"{} \; -print
 
-    # Headers (generated)
-    pushd out/Debug
-    pushd gen
-    find . $cxxfindheaders \
-        -exec install -v -D -m644 {} "$pkgdir/usr/include/skia/"{} \; -print

PKGBUILD I used for package:

pkgname=python-skia-pathops
_pkgname=${pkgname#python-}
pkgver=0.8.0.post1
pkgrel=1
pkgdesc='Python bindings for the Skia library’s Path Ops (wheel)'
arch=(x86_64)
url="https://github.com/fonttools/$_pkgname"
license=(BSD)
depends=(python skia-git)
makedepends=(cython python-setuptools-scm)
checkdepends=(python-pytest)
options=(!strip)
source=("https://files.pythonhosted.org/packages/source/${_pkgname::1}/$_pkgname/$_pkgname-$pkgver.zip")
sha256sums=('a056249de2f61fa55116b9ee55513c6a36b878aee00c91450e404d1606485cbb')

build() {
    cd "$_pkgname-$pkgver"
    BUILD_SKIA_FROM_SOURCE=0 python setup.py build
    python setup.py build_ext --inplace
}

check() {
    cd "$_pkgname-$pkgver"
    PYTHONPATH="src/python" pytest
}

package() {
    cd "$_pkgname-$pkgver"
    python setup.py install --root="$pkgdir" --optimize=1 --skip-build
}

I did not try building anything against this yet, but all checks pass.
I guess todo is to move to PEP517 system, but the biggest roadblock is to package skia properly. Current skia-git package is static library build and there is not "stable" package nor I could find easy way to get skia releases other than tracking chromium releases and use skia from that.

I'm posting it here instead of AUR comments because i think it would spam these too much.

I hope this rambling helps at least a bit.

[alerque]

I agree, everything even adjacent to Skia packaging sucks. Google's approach to build systems and software releases may work for them internally but it does not play nice with the rest of the world.

I would be happy to help push through improvements that got source builds working and/or split out Skia itself into a library package instead of being statically built & vendored in so many projects (that mostly have to use binary builds as a result).

Are you interested in opening a PR for the changes above?

[micwoj92]

Are you interested in opening a PR for the changes above?

Not possible ATM because skia-git on AUR is static build. The current package needs to change to dynamic linking or I would have to upload new one called, let's say skia-dynamic-git.
I already marked the package out of date with some improvements left in a comment, but I am not sure if current maintainer would change linking from static to dynamic. I guess it would make more sense that skia-git is dynamically linked as this seems to be standard on Arch.

Second smaller subject is the existence of only *-git package, I'd rather have something "stable" for skia.

[micwoj92]

Or does a new package called libskia-git make sense in that case?

[micwoj92]

I created PR as well as temp repo: https://github.com/micwoj92/skia-packaging

Feel free to comment and suggest improvements.

[micwoj92]

I will try to tackle this more properly again next week after froscon.

@alerque I think it would make most sense to upload "stable skia" package that would track related chromium milestones as pkgver, for example 128 with source of https://skia.googlesource.com/skia/+/refs/heads/chrome/m128.

Would you like to co-maintain that package? Should I use this issue for comments related to it?

[alerque]

I think it would make most sense to upload "stable skia" package that would track related chromium milestones as pkgver

Yes that makes the most sense. I've tried to do it before and failed though, and upstream Skia folks explicitly say they have no intention of stabilizing the ABI. The python-skia and python-skia-pathops bits needed externally are going to have a problem staying compatible with a skia package moving at the release cadence of Chromium.

I'm not saying we shouldn't try, just that they explicitly expect vendoring and design the API around that.

[alerque]

c.f. https://docs.google.com/document/d/1UnR2zKf3Z_DDRS6vLgBkSHUeqI3IGOEhWYh7rAIvsb8/edit?pli=1&disco=AAABOVoys9I

[micwoj92]

If it is as you said "finding a commit that works" then every package would need separate skia I guess? I didn't know it was that bad, I guess I had luck last time with testing latest skia-git and couple packages that depended on python-skia-pathops.

If it were to be packaged such as electron, with every chromium release equalling to new skia${version} package then I suppose it would be doable, but would need coordination that's sometimes hard on AUR. Then of course there would be problem with old releases lingering around, although that is much smaller problem in AUR than in repos.

I also don't know what you have tried so far, so it might be that I'm overly optimistic fighting this windmill.