Re: [ft-devel] FreeType Amalgamation

[Antoine Leca]

Vinnie wrote:
>> Not sure I understand all the point, but it seems to me an issue at
>> software engineering here.
> The current use-case for FreeType, and what I believe that developers
> here have the most experience with, is as a shared library on a GNU/Linux
> type system.
>
> My use-case, and that of my users, is to link with FreeType statically
I am sure there are also real users of statically-linked Freetype still
lurking around (beyond you, that is); also David certainly was such an
user when he set it up.

>> The real issue with external dependencies is about upgrading. [...]
> For my use-case vulnerabilities are a non-issue.
Okay; but my point was rather the reverse: that the only real reason
you'd want an external dependency is for the fixes; if you do not care
(and provided the redistribution licenses are in agreement), then
embedding the source is the way to go. But the form does not change that
substancially (I am not sure the fact an updating commit is lasting 1 or
200 seconds is the most important thing here.)

>> What is important on this respect OTOH, is that the amalgamationprocess
>> be realised by the Freetype project, and released through it: that way
>> any recommended upgrade could be made available with lowest delay.
> I'm not so sure this is important. The amalgamation should require only
> minor cosmetic changes to the FreeType sources. It should be possible to
> recreate an amalgamation using a simple automated tool.
Here you lost me. Are you saying that we should change the Freetype
tree, in order to allow random amalgamation tools to be run against it
by users (like you)?

What exactly is wrong (from the point of view of the user, of course)
with my proposal to have the Freetype project providing such a tool,
tailored to the specificities of Freetype?

>> Isn't already autoconf (well, really configure) task on Unix-like targets?
> Most of what autoconf does can be achieved by detecting the platform.
The same can be said of the "make config.mk" (first) step of the
semi-automated GNU make architecture, or of Jam.
As Werner noted earlier, the striking point in nowadays Freetype is that
the builds/*/*.mk fragments are not much updated (with Microsoft quickly
moving targets as an important exception...)


Antoine