Re: Build system considerations

[Ben Wagner]

Le mar. 19 mai 2020 à 10:05, Alexei Podtelezhnikov
<address@hidden> a écrit :
>
> On Tue, May 19, 2020 at 8:09 AM Hugh McMaster <address@hidden> wrote:
> > Is there any opportunity to avoid modifying ftoption.h directly to
> > enable, say, subpixel rendering with a new build system? Carrying
> > permanent patches for downstream packaging is annoying.
>
> [Presently, FT_CONFIG_OPTION_SUBPIXEL_RENDERING only alternates
> between ClearType and Harmony algorithms. Most users won't be able
> to tell them apart.]

Note that some users of FreeType are never going to use subpixel
rendering at runtime and could do without the code. The actual amount
of code is pretty negligible, but if they are never going to use it
it's just extra weight, so it's nice to be able to configure it out,
no matter how small the extra code for it is.

> > Personally, I'd like to be able to enable various options via
> > configure flags or a configurable file (JSON, anyone?) that's not a C
> > header. Python could do nicely here.
>
> One would think that modules.cfg is a configurable file like that but it turns
> out that Chromium finds special ftmodule.h more convenient. We also have to
> accommodate the less fortunate without Python on embedded systems.

Chromium currently finds the ftmodule.h a convenient way to tell the
runtime (ftinit.c ft_default_modules) which modules got built at build
time. If there were a particularly better way to do that I don't think
there would be much difficulty adapting. For example if the whole
service / module structure went away and libfreetype just always did
what was built and the list of modules to be loaded at library init
didn't need to exist then we'd just build what bits we needed in each
build and drop the ftmodule.h customization bits.

> Some choices in FreeType, including the service and module infrastructure and
> very lean external dependencies, has helped it to spread so widely.
>
> > Other than that, the removal of RPATHs should be revisited. That's a
> > topic for another thread.
>
> Ok.
>
> Alexei
>