>>...there are several macros that would not work if all sources are >>concatenated. ...An example is GET_PIC() macro defined by >>src/xxx/yyypic.h. and src/xxx/ttpic.h > > Isn't this easily fixed by renaming one of the #define and changing > the appropriate source files?
We will do so. >>I neither have time nor energy to change that. It's there since ten >>years, and it works essentially everywhere. Note that there are >>other packages which do similar things, for example `boost'. > > Sure, but it gets in the way of an amalgamation. It can be worked > around though. However, what is the purpose? Is there ever a > situation where FT_GLYPH_H is defined to something other than what > exists in the header file? The user has the flexibility to do so. With a specially crafted ftheader.h file, you can e.g. put all header files into one directory, both at build time and after installation. >>How shall this work? There are dozens of platforms, and you want to >>hard-code them all in a configuration header file? > > Yes, that is the hope. This is the approach taken by boost. Maybe this works for C++ since it is a newer, stricter standard, but for C I fear you'll find a platform where this fails. > 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 nice suggestion but this doesn't get us much. I prefer a > requirement of passing -l flags to the amalgamation tool to inform > it of all the directories to search for includes, because this way > someone who wants to produce an amalgamation does not have to > re-shuffle the FreeType source tree after they check it out. Is your amalgamation tool freely available source code which I can build by myself on GNU/Linux? 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. >>There were good reasons for it which you might look up in the >>archives. > > How do I look this up? The list archive is here: http://lists.gnu.org/archive/html/freetype-devel/ Here David has announced the change: http://lists.gnu.org/archive/html/freetype-devel/2000-12/msg00025.html The corresponding commit in the git repository is 8fba32d2d6f284bfd49ed6c0557880e0bb692f49 Werner _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
