Re: [ft-devel] FreeType Amalgamation

[Vinnie]

Amalgamation tool is here:

http://code.google.com/p/amalgamate/

>I repeat it: It's not possible to make FreeType work on all platforms
>with preprocessor macros only.

I'm not so sure about that. I looked at all of the stuff in the builds directory
and it would seem that the bulk of platform differences have nothing
to do with the code but rather, the build tools.

With the amalgamated distribution format, the work of setting up the
build environment is offloaded onto the programmer. It is assumed that
they already have a project that builds correctly, so to use the amalgamation
they only need to add an additional .c file to the already-working
project.

>> 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.
>
>Again, this is the Windows philosophy...Every project/program must
>come with everything it needs.  No chance to reuse...components reliably. 

Yes, and I would call this a feature rather than a deficiency. I WANT
my app to come with everything it needs, this way it always behaves
predictably. That's why I link with the C runtime statically, instead of
opening myself up to the mess caused by shared libraries (a.k.a.
"DLL hell").

>However, given that FreeType is used in virtually all smartphones,

>reaching a wider audience is probably not a big issue for us :-)

Well when I speak of audience I am talking about the programmers and
not the devices on which the application runs. Here is a typical use-case:

1) Musician (the user) discovers DAW (digital audio workstation) software
like ProTools

2) User learns about audio plugins which can produce filtered effects and
also act as synthesizers or sequencers.

3) User decides they want to write their own plugin and starts reading up.

4) User realizes they must first learn C/C++, and downloads an existing
open source plugin to see how it works.


So this is the typical user for a Freetype amalgamation. 90% of the time
they are running on a Mac OS X workstation or laptop that has some
music software installed.

The other 10% are running on Windows, and will end up downloading
Visual Studio Express (the free version) to try their hand at plugin authoring.

Most of these plugins are written using a framework like Juce, that
handles almost all of the plugin format specific details, as well as
all of the platform specific details. Juce has a robust API for putting up
a fancy gui, with the benefit that this gui works on all platforms.

Plugin authors always want to have very fancy interfaces with realistic
looking knobs, sliders, and meters with color blends, shadows, and
transparency effects but equally importantly the display of crisp text
at small point sizes and thats where FreeType comes in.

To gain complete control over the gui and make sure that pixels always
land in the right place, instead of relying on a system provided font
(which may or may not exist) fonts are embedded in the plugin or
host application and used consistently, ensuring that the layout of
gui elements is always predictable.


>>  The amalgamation should work with all platforms that FreeType
>>  currently supports, of course!
> 
> This, I believe, is an illusion.  You'll certainly find a compiler
> which fails to compile without proper autoconf configuration.  Maybe
> it's better to restrict amalgamation on a subset of supported
> platforms.

Well like I said, looking through the ./builds/ directory it seems that
almost all of the platform differences are related to the build environment
and not C language / compiler specifics. Since a requirement of the
amalgamation is that the user provide an already-working project
in which to drop the large .c, this becomes a non-issue.

> Is your amalgamation tool freely available source code which I can
> build by myself on GNU/Linux?

Yes it is. The tool is based on the Juce amalgamator, with some of
my own additions to support FreeType. I made the new features as
general as possible - there is nothing specific to FreeType in it. In
particular, I added all of the command line switches -d, -i, -w, -s.

You can get the sources here:

http://code.google.com/p/amalgamate/

Don't expect miracles, I started a day ago. There is only a Visual
Studio 2010 project file, but you should be able to build it under
your favorite platform by compiling the .cpp files and linking them
with the right libraries.

There is a "FreeType" directory in the repository that has the
FreeType amalgamated template, as well as a batch script that
calls the amalgamation tool with suitable parameters.

On my machine I am able to produce an amalgamation that compiles.
I had to make the changes I wrote about in previous posts, regarding
duplicate symbols.

There is one lingering issue with fterror.h, since it gets included
multiple times. I'm not sure how I will fix it.

> Having a `make amalgamation' target within FreeType is the right route
> to go IMHO.  Whether this uses your tool or another one (possibly
> hand-crafted) is not so important.

Yeah having that target would of course be great but it adds a continual
load to FreeType developers since the amalgamation would now need
to be maintained. For this reason I prefer making the cosmetic
adjustments to the source tree, this way they are baked in and in theory
would need less ongoing attention.

>>  This is what I mean by "cosmetic" changes.  It looks like 
>> ftgrays.c was born as a copy of the file ftraster.c and modified
>>  appropriately, thus the duplicate symbol names.
> 
> Indeed.  Can you provide patches, splitting the discussed issues into
> logical change sets so that I can easily add them to the git
> repository?  I suppose that you have git support installed...  And can
> you provide proper ChangeLog entries also (following the format given
> in this file)?

Ermmm....I haven't used git to be honest. I just pick up the archive and
extract everything locally. And to make matters worse I'm working on
a FreeType which is a few revisions old. I need to get the latest FreeType
and reapply all of my changes, using the naming convention you outlined
in these posts.

> Again, please send patches!

Can I send all the changes in one large .diff from the tip?

>>  5) Where are ftimage.h and inttypes.h?
> 
> This is special.  Please read the comment at the top of `ftraster.c';
> the direct inclusion of those files (not using macro names) only
> happens in stand-alone mode.

I see. stand-alone compilation mode is not relevant for an amalgamation
so there is no issue with these files.

Thanks

Vinnie