Re: [ft-devel] FreeType Amalgamation

[Vinnie]

>>>  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.)

If someone gets my demo app and they want to use it as the foundation
for a new project, then every time FreeType has changes, the process for
retrieving an update is more complicated, if there are new files, renamed
files, or removed files. 

It is not obvious from looking at just the FreeType source tree which .c files
actually get compiled, versus which .c files are simply included.

Furthermore, creating a new project that used a deep copy of the FreeType
source tree (so that the published project was self contained) is more elaborate
than creating a new project that uses an amalgamation (which is as easy
as adding two files).

The amalgamated distribution format is more convenient for the use-cases
contemplated.

> 
>>>  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)?

Not sure what you mean by changing the tree. Flattening all the sources?
No that shouldn't be needed. The problem with ftconfig.h is more involved,
there would need to be a preamble that decodes the platform, and then
all the different incarnations of ftconfig.h rolled into one header that
has conditional preprocessing directives.

> 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?

>From the user's perspective nothing, but putting FreeType specific
smarts into a separate tool, to me seems like misplaced effort. Better
that the FreeType sources are tweaked, this increases the chances that
the amalgamated sources will work in more environments without
requiring changes to a build tool. I'm not a fan of build tools, they
are just another piece of software that can break. Ideally, the existing
Juce amalgamator tool would work (its not Juce-specific).

I'm having a little bit of success with using this tool. I have created a file
ftamalgam_template.c this is the contents:

/* This template file is the input to the amalgamator */
/* internal headers */
#include <freetype/internal/ftobjs.h>
#include <freetype/fttypes.h>
/* sources */
#include "src/autofit/aftypes.h"
#include "src/autofit/afdummy.h"
#include "src/autofit/aflatin.h"
#include "src/autofit/afcjk.h"
#include "src/autofit/afindic.h"
#include "src/autofit/autofit.c"
#include "src/bdf/bdf.c"
#include "src/cff/cfftypes.h"
#include "src/cff/cffparse.h"
#include "src/cff/cff.c"
#include "src/base/ftbase.c"
#include "src/base/ftbitmap.c"
#include "src/cache/ftcache.c"
#include "src/base/ftdebug.c"
#include "src/base/ftfstype.c"
#include "src/base/ftgasp.c"
#include "src/base/ftglyph.c"
#include "src/gzip/ftgzip.c"
#include "src/base/ftinit.c"
#include "src/lzw/ftlzw.c"
#include "src/base/ftsystem.c"
#include "src/smooth/smooth.c"
/* modules */
#include "src/base/ftbbox.c"
#include "src/base/ftmm.c"
#include "src/base/ftpfr.c"
#include "src/base/ftsynth.c"
#include "src/base/fttype1.c"
#include "src/base/ftwinfnt.c"
/*#include "src/pcf/pcf.c"*/ /* THIS BREAKS */

Unfortunately when the amalgamated result is compiled, I get a cryptic error
with FT_ULong. And I have not addressed the problem of macros appearing
in include lines, or the use of angle brackets. But its a start.

>>>  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...)

At the risk of losing credibility I will admit that I have never actually used
autoconf and I have no idea what mk fragments are. All of my experiences
with using these tools have been negative. When I download sources
and I see those files it brings a bad taste to my mouth. All of my development
is done on Windows in Visual Studio. I use XCode for testing Macintosh and iOS
builds, and rely on my users for the rest.

I much prefer that intelligence about handling platform specifics be
embedded in the header files and detected through the use of preprocessor
directives. This is the approach used by Juce and sqlite. It has the benefit
that fewer tools are involved in the build pipeline, and thus less things to 
break.
And when there is a build problem, it is isolated to a smaller number of
components so there is less to search for the defect.

Designing a library's sources so that pre-build steps are not necessary
also lets you reach a wider audience - it is a fact that external dependencies
cause you to lose some non zero percentage users. Namely, those that can't
be bothered to install or don't know how to use the additional tools.