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!
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Reply via email to