>> 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 _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
