On Thursday, 13 July 2023 at 22:46:38 GMT+8, Hugh McMaster
<hugh.mcmas...@outlook.com> wrote:
> 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 :-).
