> If we are going to overhaul the build system, I’ve long wanted to have FreeType demos build as a separate package that links against a system-installed FreeType library (not the source directory).
I second that! I think only ttdebug definitely wants to link against freetype at the source/private header level. You can see my skeletal makefile for ftinspect that it is using system freetype and that seems to work okay. I think the majority of ftdemo can work against a stock system freetype+public header.
> That’s how we detect python3 and librsvg (although I wish there were a lighter library available). That said, there’s certainly an argument for alternative approaches.
I don't know if rsvg does its own xml parsing or farms it off to libxml2 (for example), but the task of xml parsing itself is a library of its own in every programming language. The Java library for SVG, batik, is quite large too.
rsvg + cairo is about 7MB shared libraries; linking skia in adds about 25MB static - I suspect all the svg parsing in rsvg if done in static might come to a similar size. I have a small impression that skia-enabled ft2-demo is marginally faster than rsvg+cairo, but this is probably something for our GSoC students to measure/confirm/dispute :-).