Use brand new PKGBUILD for Aseprite Package

[ISSOtm]

This attempts to fix the old one's jank.

• Dependencies are pulled via the bundled script for more reliability
• Less static libs = yes
• CMAKE_BUILD_TYPE set to None to use Arch Linux's build flags
• Use bundled gn (Arch Linux's gn package appears to use an incompatible version. Whatta shame!)
• Use libxxx dependency specifications (where possible) to pin lib versions and avoid breakage
• $pkgname only used where it would help "forking" the PKGBUILD, i.e. not in source links, for example
• Python 2 not required to build
• Removed conflicts with other aseprite variants, as they will conflict if they properly provides and conflicts with aseprite

TODOs:

• [x] Not all dependencies checked out by git-sync-deps are necessary, since a lot of shared libs are used. Figure out a way to only sync what we need?
• [x] Make libwebp shared as well? Could use https://github.com/aseprite/aseprite/pull/2523 as a base.
• [x] namcap complains that libexpat and libharfbuzz are not used, despite ldd's output. I'm a bit puzzled.
• [x] Is icu required at runtime? It's not linked to, but I *think* the headers might be required nonetheless. (Unfortunately, verifying this is a bit difficult.)
• [ ] Run tests? E.g. LAF's, except that they fail to build due to an obscure linker error (looks like some static lib requires a dynamic lib that doesn't get -l'd?)
• [x] Make sure we have feature parity with the current PKGBUILD, e.g. I noticed this one doesn't install icons in the same location
• [x] Did I miss any makedepends? Nothing direct for sure, but maybe some transitive dependencies (e.g. Python 2 was only required by a script indirectly invoked via gn)
• [x] Should we require clang? Skia's build instructions mention that performance may be significantly worse with non-Clang compilers
• [x] Do we really conflict with skia-git? If so, that should be reinstated in the conflicts array

(Aside: if you'd like, I can be a co-maintainer of the AUR package as well.)

[ISSOtm]

Findings about build deps:

• freeglut appears to only be required by imgui examples (we don't build them) and libwebp's vwebp (we don't build it either)
• I think the following transitive dependencies can be safely left implicit: xorgproto ← libx11 ← libxrender ← [ libxcursor ; libxrandr ]. libxrandr is required by a few third-party files, but is not linked against in the final binary, so I'm not entirely sure.
• nettle is depended upon by curl and libarchive, but we use shared libs for both, so it can be removed
• harfbuzz-icu is required by Skia... unless using the bundled version. So we can also get rid of the dependency.

[ImperatorStorm]

Add yourself on as a Maintainer and I'll merge.

[ISSOtm]

Thank you very much! Do we want to merge with the first post's TODOs still unresolved?

[ImperatorStorm]

Now that you mention it,

Not all dependencies checked out by git-sync-deps are necessary, since a lot of shared libs are used. Figure out a way to only sync what we need?

This should be done before merge Everything else was either already fixed or is fine.

Perhaps patching DEPS to only grab the dependencies we need it to grab?

Alternatively, manually sync the deps?

[ISSOtm]

I'm not sure which of these options is best. I'd rather sync them manually to avoid patching, but this might be cumbersome.

I'm also looking into dependencies again, especially icu which is not linked against despite skia_use_system_icu=true... tbh, it's quite hard to trace through all of the dependency chain.

[ISSOtm]

Ok, so, passing -v to ninja, and then grep -o -- '-I\s*../third_party/externals/\S*' | sort | uniq, it follows that only freetype and libgifcodec are being used, at least like this.

More investigation is required, since I remember not being able to compile without at least dng_sdk. But at least we should be able to get somewhere.

[ISSOtm]

Looking at src/skia/gn/skia.gni, it seems that the components that are being used are:

Component	Used?	Reason
expat	No	Using system's
fontconfig	No	Using system's... I think?
freetype	Yes	Using system's freetype2, but the bundled harfbuzz requires freetype (!)
harfbuzz	Yes	Can't use system's due to an API change, apparently, so must use bundled
gl	No	??
icu	No	Using system's
libjpeg-turbo	No	Using system's
libpng	No	Using system's
libwebp	No	Using system's
piex	No	Must use bundled
x11	No	??
xps	No	??
zlib	No	Using system's
dng_sdk	Yes	By default if using libjpeg-turbo and zlib... huh.
libgifcodec	Yes	By default if not using wuffs
sfntly	No	Enabled by default since we use icu, but Aseprite's build instructions disable it... except in the Linux example??

This table needs more work, esp. figuring out which libs are required for what (mainly, what file formats does Skia need to load? What is handled directly by Aseprite?) So consider the above a WIP. (Thankfully, we can already get rid of a lot of deps—many of them, such as imgui, are only used for building example programs, so we don't need them either.)

Looking at the various BUILD.gn, it seems that is_official_build sets use_system_*=true by default, so that would also simplify the gn config line.

I am also disabling skia_enable_pdf and skia_enable_skottie, as it seems that Aseprite uses neither. This should reduce the compile time.

[ISSOtm]

Ok, this should suffice for all the "cleanup" commits, and I've taken out 4 items from the OP's TODO list. I noticed that PDF support isn't actually disabled! Only some parts of it are, right now. I'll next look into axing that.

I'll check if e.g. disabling libpng causes Aseprite to fail linking, since I know for a fact that it expects to load and save PNG images. If it does, then we should be able to rely on disabling required features failing to build entirely; otherwise, we'd see missing features only have an impact at runtime.

Regardless, the bulk of the work should be done—I still have a lingering fear that I broke something with this amount of changes, but it compiles and runs fine for me—so this should be ready for review.

[ImperatorStorm]

Workflow failed, missing libglvnd makedependency, possibly runtime dep.

[289/912] compile ../src/gpu/gl/glx/GrGLMakeNativeInterface_glx.cpp
FAILED: obj/src/gpu/gl/glx/gpu.GrGLMakeNativeInterface_glx.o 
c++ -MD -MF obj/src/gpu/gl/glx/gpu.GrGLMakeNativeInterface_glx.o.d -DNDEBUG -DSK_R32_SHIFT=16 -DSK_GAMMA_APPLY_TO_A8 -DSKIA_IMPLEMENTATION=1 -DSK_GL -I.. -fstrict-aliasing -fPIC -O3 -fdata-sections -ffunction-sections -Wno-unused-parameter -std=c++17 -fno-exceptions -fno-rtti -c ../src/gpu/gl/glx/GrGLMakeNativeInterface_glx.cpp -o obj/src/gpu/gl/glx/gpu.GrGLMakeNativeInterface_glx.o
../src/gpu/gl/glx/GrGLMakeNativeInterface_glx.cpp:15:10: fatal error: GL/glx.h: No such file or directory
   15 | #include <GL/glx.h>
      |          ^~~~~~~~~~

[ISSOtm]

Something else: I'm noticing that the old PKGBUILD disabled the updater, but I currently am not (and thus it's enabled by default). Should we disable it?

[ImperatorStorm]

Yes, updater's likely gonna be broken with this packaging.

[ISSOtm]

New build fail, this time it's related to libwebp. I'll look at it tomorrow.

[ImperatorStorm]

Alright.

[ISSOtm]

Side note: I don't like that libwebp is being linked against dynamically by Skia, but not by the final executable. I'm a bit rusty on my static lib innards, but it seems possible that we'd be compiling Skia against the system headers, but linking against Aseprite's bundled lib.

[ISSOtm]

Yeah, I am afraid that's what's happening. The fix seems to be making the same lib consistently shared or static in both Skia and Aseprite.

For libwebp, we should make it shared by Aseprite as well; for freetype and harfbuzz, we should make Skia point to Aseprite's bundled headers (or the opposite, whichever works). I think that should work.

[ImperatorStorm]

pushed a commit based on https://patch-diff.githubusercontent.com/raw/aseprite/aseprite/pull/2523.patch, hopefully this fixes the libwebp issue.

Well, that's certainly an error

oh, its USE_SHARED_WEBP not USE_SHARED_LIBWEBP

[ImperatorStorm]

Also adding on pixman as a makedep, as we're using the shared library of it in aseprite.

[ImperatorStorm]

Ok ld failed to link, not sure what's going on there.

ld wants WebPDemux and WebPMux stuff, though it should have been built.

gif2webp or img2webp is required to get libwebpdemux

Hmm, -DWEBP_BUILD_GIF2WEBP=YES should be building it, not sure why ld's complaining.

2022-01-05T07:02:55.3726080Z CMake Warning: 2022-01-05T07:02:55.3727021Z Manually-specified variables were not used by the project: ... 2022-01-05T07:02:55.3729311Z WEBP_BUILD_GIF2WEBP 2022-01-05T07:02:55.3729704Z WEBP_BUILD_IMG2WEBP ...

Odd, looks like shared libwebp breaks this.

[ISSOtm]

That'd be normal, as libwebpmux and libwebpdemux are also part of libwebp.

[ISSOtm]

Seems like this works just fine, and I also managed to make harfbuzz and freetype shared :)

[ISSOtm]

Also adding on pixman as a makedep, as we're using the shared library of it in aseprite.

The shared lib doesn't appear to be used, since the LAF backend is Skia. I'll check if we can skip having it installed at all.

[ImperatorStorm]

Should we require clang? Skia's build instructions mention that performance may be significantly worse with non-Clang compilers

Regarding this, it would likely be best to require clang.

[ISSOtm]

Thing is, I don't know if it really holds true anymore. But I don't know how we'd bench performance either.

[ImperatorStorm]

Fair, might be best to not force clang then.

[ISSOtm]

Ah, I see that Skia's source has a bench subdirectory. Gimme a while to look at that.

[ISSOtm]

Looking more into it, it doesn't seem like it would make sense to bench Skia itself, but we'd be more interested in how Aseprite uses it. So I don't know. Maybe we should stick to the default for now (which can be configured in makepkg.conf, mind you), and pin a message in the AUR comments telling users to report any performance issues. Based on feedback we can then choose whether to require Clang.

[ImperatorStorm]

sounds good.

[ImperatorStorm]

Do we really conflict with skia-git? If so, that should be reinstated in the conflicts array

I can't imagine why we'd conflict with skia-git, probably shouldn't re-add it to conflicts.

[ImperatorStorm]

Run tests? E.g. LAF's, except that they fail to build due to an obscure linker error (looks like some static lib requires a dynamic lib that doesn't get -l'd?)

Should probs give it a try.

[ISSOtm]

No, we shouldn't conflicts with them. They should provides us, and also conflicts with us.

[ISSOtm]

Do we really conflict with skia-git? If so, that should be reinstated in the conflicts array

I can't imagine why we'd conflict with skia-git, probably shouldn't re-add it to conflicts.

I was thinking there could be a lib search path conflict, but I really don't think it can happen, so this is very likely the right move imo.

[ISSOtm]

The last thing I want to check is compiling less things into Skia, to reduce build time. My plan is to remove libs and see if compilation fails. AIUI, since we are statically linking to Skia, if a function relied on by Aseprite is not present, we should get a build-time error. (Right?)

[ISSOtm]

Bruh, I'm stupid.

[ISSOtm]

Sorry about that, I added the missing file. My bad!

[ImperatorStorm]

Run tests? E.g. LAF's, except that they fail to build due to an obscure linker error (looks like some static lib requires a dynamic lib that doesn't get -l'd?)

Should probs give it a try.

wait on this or merge?

[ISSOtm]

Good enough imo. Let's not wait indefinitely on the changes.

[ImperatorStorm]

Manually merged into master.

Thanks for rewriting the package!

[ISSOtm]

Thank you for collaborating as well! :)

[ImperatorStorm]

squash+merged into aseprite because AUR got mad when i tried to push aseprite.