Comment by tony | Hacker News Reader

Comment by tony | Hacker News Reader

Aseprite switched to Skia a year or so ago (https://github.com/aseprite/aseprite).

Regret it. Google doesn't care to maintain CMake support for it, so there goes pulling it in via source and building as a library dependency. https://github.com/aseprite/aseprite/issues/1598#issuecommen...

You may ask, "why don't you just write your own CMake module like everyone else?" I've tried. I think the build system changed a bit since, but back when I last tried, it required grabbing depot tools, checking out a source tree and a ton of other dependencies.

I am the original person that got Aseprite building on FreeBSD - but now I can't build it on any platform at all. Skia has too many points of failure in the build process. (Here's another issue where I spend hours trying to figure out what's going on https://github.com/aseprite/aseprite/issues/1081)

Every other graphics library (SDL2, Allegro, SFML) can work with CMake.

Another pain point: Skia isn't on any package managers to my knowledge. Here's the debian RFP https://bugs.debian.org/818180.

It's true. Google has essentially made it as painful as possible to use Skia outside of the google ecosystem. The build system is what's mostly kept me from using it in personal projects.

Xamarins wrapper for C# made it a breeze to use from C# at least - just add the package. The same is likely true for all ecosystems with reasonable package management. It’s only ironic that C++ libs are hardest to use from...C++

Sadly a consequence of the C culture that was adopted in C++ regarding how libraries should be distributed, before the time of package managers.

Just checked, and Skia is not to be found anywhere across vcpkg, Conan, Hunter, Ubuntu, Debian.

So using C# sounds much better than having to understand Google specific build processes to compile it.

I believe that... but the only reason why is they bent over backwards to come up with something that works today, and likely won't work in another 3 months, given the rate of turnover of build systems.

This must be Google's "strategy" for keeping people from profiting off of their open source code. I've encountered so many of their "open source" projects that are nigh impossible to build without having a Googler sitting in a chair next to you, walking you through all the unrecorded changes to the build process since the last time the documentation was updated.

Skia team here- We had an experimental cmake build that we let go last year, but sounds like there is more interest in it than we thought. It should not be hard to restore it, so we've got it on our todo list now.

Out of curiosity, aside from the obvious disadvantages you mentioned, what advantages does it bring to the table? Long-time casual user of Aseprite. To be honest, I never knew it was open source until just now, I actually own a couple copies.

Allegro, SDL2, SFML, et al. do more things (audio, joystick support, keyboard/mouse events) across platforms. Skia does one thing really well, 2D graphics.

There is a ticket open for building an abstraction layer @ https://github.com/aseprite/aseprite/issues/139

In terms of Aseprite:

> > But what made it the choice over Allegro 5, SFML, and SDL2?

> through all these years I reached to the conclusion that you need full control of mouse and keyboard messages (and all window messages in particular, e.g. to give proper support to pen/stylus). [1]

[1] https://github.com/aseprite/aseprite/issues/139#issuecomment...

OK, I agree with the sentiment. SDL2 is probably the closest to doing the right things, but even then you're on your own with the stylus APIs mostly.

So far, the only library I've used that can properly abstract graphics tablets across platforms is Qt, and in the past it has been sometimes rough around the edges with support for it. I think on Windows it is still using the Wintab32 API and not the newer Windows 8 Ink APIs, for example.

I’d be grateful to see some sort of build log from a successful run with this frankenbuilder and try making a traditional BSD Makefile.

Reply on news.ycombinator.com