Re: [ft-devel] FreeType Amalgamation

[Vinnie]

>>  I'm afraid that MacOS specific ugly hacks (detecting Mac OS,

>>  excluding CodeWarrior, detecting Mac OS X, excluding PPC, excluding
>>  64bit, etc etc) made Vinnie feel sick.
> 
> I don't think so :-) If I understand him correctly, he would like to
> configure everything with platform-dependent macros in a single header
> file.

Yes that's right. As Werner said, I would like all of the configuration to
happen during the preprocessing phase and not in a separate configuration
step, automated or otherwise.

>>...For Freetype 2 (b. 1999), David went away from this scheme, in my eyes
>> for the benefit of a much increased modularity
> I do not know if it still useful. Voices?

It should be possible to produce an amalgamated version of FreeType that
requires only cosmetic changes to the source tree. Certainly nothing radical.
It is not necessary or desirable to change FreeType's current structure,
which consists of modules.

> 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.e.
it is "baked in" to the application). We then embed a font directly in
the application. For example, by using an automated tool that converts
a binary file (the font file) into a static variable in a .c file defined as an
array of bytes.

The font is loaded at run-time using the statically linked FreeType. Note that
even on a Linux system, FreeType is still linked into the application 
statically,
and we DO NOT directly use the FreeType shared library that is already
on the platform. However, if the X11 window system or underlying graphics
layer uses FreeType, we might indirectly use FreeType (if we use fonts
other than those embedded in the application).

The reason that we want to use a statically linked version of FreeType is
for regression and testing. There is no possibility of a different version
of the library getting used: we know that the end-user experience is not
going to change.

With FreeType in conjunction with Juce it is possible to develop a gui
application that runs on Windows, MacOS, iOS, and Android devices
and looks the same for all the platforms.

I needed FreeType to get hinted output in Juce for small sizes of my font.
This is the code I wrote:

http://rawmaterialsoftware.com/viewtopic.php?f=6&t=6393

> The real issue with external dependencies is about upgrading. If we have
> a look over the last 10 years of Freetype history as condensed into
> docs/CHANGES, most version bumps are either bugfixes for some previously
> introduced changes, or vulnerabilities fixes. Both are good reasons to
> upgrade as soon as possible the version of Freetype in use.

For my use-case vulnerabilities are a non-issue. The user never has the
opportunity to choose a font file. If there is a bugfix, then the amalgamation 
is
recreated, the client application is rebuilt, and a new version distributed.

> 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. I am using the Juce
amalgamator as the starting point. It is the one I used to produce the Juce
amalgamation in DSP Filters Demo.

> This is in opposition to a in-house flattening of the Freetype tree integrated
> into a bigger project, where any further upgrade is then dependent on that
> developer willingness and availability...

Right, and developer willingness is exactly what should drive the upgrade
process of the amalgamation. The simple fact is that since I started using
FreeType 2 years ago, none of the bug fixes or patches has helped me. But
don't stop the fixes on account of me! It's just that I'm using FreeType in
a very narrow use-case. Specifically, I'm using FreeType to load my own font
embedded in the application, extract hinted outlines, and draw it using the
Juce renderer.

>> True, this could be done by creating a deep clone of the entire FreeType 
>> source tree but this is a bulky solution.
>
> I am not sure this is as bulky as you seem to imply.

Yeah its pretty bulky, because every time FreeType changes, anyone who is
redistributing the sources has to commit several files instead of just one or 
two.
What happens when a file is added, moved, or renamed? Anyone who has
added FreeType to their project as a set of sources may need to maintain
their project file.

Compare and contrast this with an amalgamation. For most of the latest
FreeType fixes, only one file would have changed (the big .c).

> Something I do see as bulky though is about bug reporting, more exactly
> about patch contribution: any fix provided against such big files cannot
> be applied to the "regular" source tree

Patches are never applied to amalgamations, nor are amalgamations ever
modified directly. Changes are made to the original sources, and then the
amalgamation is recreated.

It is important, however, for the amalgamation to retain most or all of
the original formatting and comments, since developers may need to step
through it with a debugger during testing.

>>  3) Depending on the platform, there might be a different ftconfig.h and/or 
> ftmodule.h needed (possibly other sources too)
> This OTOH is about library customisation (or tailoring.)
> ...
> ...you want Freetype to be customisable, and not only depending on
> the underlying platform...

I agree completely. The approach taken for the Juce amalgamation is for
the source files to include a "configuration" header, which optionally
defines macros that customize the feature set of the resulting FreeType
build.

In the Juce amgalamation for DSP Filters you can see that there is a file
called "AppConfig.h":

http://code.google.com/p/dspfilterscpp/source/browse/#svn%2Ftrunk%2Fshared%2FJuceAmalgam

This file is included before the "big .c files" containing the amalgamated 
sources.
It controls the resulting feature set. For example, you can set
JUCE_USE_XINERAMA or JUCE_ALSA to 0 or 1 depending on whether
you want that feature. Of course if you use these features you have to link 
with the
appropriate libraries.

The FreeType amalgamation would work the same way. It would come with
a config header file. Whoever uses the amalgamation can decide what
features are suitable for their app and adjust the header file accordingly. 
These
configurations should be completely separate from the platform-specifcs
required to build, however.

> Isn't already autoconf (well, really configure) task on Unix-like targets?

Most of what autoconf does can be achieved by detecting the platform. Note
that the DSP Filters Demo app doesn't need or use autoconf, or even a
Makefile. These lines should suffice to build the demo for the bulk of
systems:

unzip DSPFiltersComplete_0_9_72.zip
cd shared
g++ -o dspfiltersdemo $(find DSPFiltersDemo DSPFilters -name \*.cpp) 
JuceAmalgam/JuceLibraryCode*.
cpp
 -I JuceAmalgam -I DSPFiltersDemo/source/ -I DSPFilters/include/ 
$(pkg-config --cflags --libs freetype2 alsa) -ldl -lpthread -lrt -lX11 
-lGL -lGLU -lXinerama -lXext

Thanks