freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ft-devel] FreeType Amalgamation


From: Vinnie
Subject: [ft-devel] FreeType Amalgamation
Date: Thu, 19 Jan 2012 08:32:22 -0800 (PST)

I'm interested in building an "amalgamated" version of FreeType. Specifically, I would like to use an in-house tool to combine all the FreeType headers and source files into a set consisting of a single .h and .c (or a couple of .c files if they are too large). This amalgamation would be much easier to use - instead of requiring a bulky Makefile or IDE-specific project file, one could just add the .c to an existing project. For my purposes, there is value in being able to distribute a project that uses FreeType, but has no external dependencies (i.e. someone does not need to visit a separate source code repository to obtain freetype). True, this could be done by creating a deep clone of the entire FreeType source tree but this is a bulky solution.

As FreeType is a very mature project that is now quite stable and not undergoing much change, providing an amalgamated format seems useful.

There are some other open source products that exist in amalgamated form. For example, sqlite:
http://www.sqlite.org/amalgamation.html

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

Unfortunately, creating an amalgamated version of FreeType would require some changes to the way that source files are organized. Three issues come up:

1) Some FreeType #include statements use angle brackets instead of double quotes. e.g. #include <ft2build.h> Why?

2) Some FreeType #include statements use macros, like "#include FT_GLYPH_H". This complicates automated tools.

3) Depending on the platform, there might be a different ftconfig.h and/or ftmodule.h needed (possibly other sources too)

My comments:

2) I looked at some of the macros and it seems they are all set in internal.h. I don't see any compelling reason why it is necessary to use a macro in the #include line. I've been programming for close to 30 years now and this is the first time I've seen a macro used this way.

3) A new ftconfig.h should be created that has a preamble for decoding the platform, and all of the separate ftconfig.h / ftmodule.h rolled into a single .h that uses preprocessor definitions to select the appropriate set of code. Alternatively, the platform specific header files can be given unique names (e.g. ftmac_config.h, ftmac_module.h) and then get conditionally included. Like this:

#if FT_PLATFORM_MAC
#include "ftmac_config.h"
#else
#include "ftgeneric_config.h"
#endif

These problems could be overcome a different way, by writing a custom script that does most of this work. This script would be fairly hefty to work around these issues and would be quite FreeType-specific. It would also need maintenance and testing every time FreeType changed. The resulting amalgamation would likely only work on one platform - it would be necessary to have a different amalgamation for each platform the way the source files are structured now (with some platforms having their own ftconfig.h / ftmodule.h). Because of this, I have little to no motivation to write such a customized script, I prefer to be able to use a generic tool that does not need to know about FreeType specifics.

What is the level of desire for bringing about these changes?

Thanks!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]