> 1) Some FreeType #include statements use angle brackets instead of > double quotes. e.g. #include <ft2build.h> Why?
This is to control inclusion with the -I command line flag of the compiler. Think of build_dir != src_dir (which is very common on Unix boxes). > 2) Some FreeType #include statements use macros, like "#include > FT_GLYPH_H". This complicates automated tools. 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'. > 3) Depending on the platform, there might be a different ftconfig.h > and/or ftmodule.h needed (possibly other sources too) Exactly. In normal Unix builds (and today we develop on Unix boxes), this is easily controlled with the -I compiler flag. > 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. There are certainly other possibilities to do it. > I've been programming for close to 30 years now and this is the > first time I've seen a macro used this way. Note that David Turner developed the current macro inclusion scheme while working on a *Windows* box more than ten years ago, so it is not the result of sick Unix programmers :-) There were good reasons for it which you might look up in the archives. > 3) A new ftconfig.h should be created that has a preamble for > decoding the platform, [...] How shall this work? There are dozens of platforms, and you want to hard-code them all in a configuration header file? Let me ask it differently: What platforms are you going to support? A generic solution needs configuration done by an external tool (e.g. autoconf), but this somehow contradicts your idea of simply having everything in a large file.[1] > These problems could be overcome a different way, by writing a > custom script that does most of this work. [...] Not a good solution, I admit. > I prefer to be able to use a generic tool that does not need to know > about FreeType specifics. This would be ideal, of course. Given the many problems, I suggest a step-by-step approach, and I hope that you can assist, test, and develop. FreeType already supports flat-directory compilation (see docs/INSTALL.ANY), maybe this is a good starting point. Werner [1] BTW, I suggest that you have a look at the `gnulib' repository to see how many broken stuff is floating around in the world. http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=tree Just to give an example, here some documentation regarding the `sprintf' function: sprintf ------- POSIX specification: http://www.opengroup.org/onlinepubs/9699919799/functions/sprintf.html Gnulib module: sprintf-posix Portability problems fixed by Gnulib: $(Q#@(B This function does not support size specifiers as in C99 (hh, ll, j, t, z) on some platforms: AIX 5.1, HP-UX 11.23, IRIX 6.5, OSF/1 5.1, Solaris 9, Cygwin 1.5.24, mingw, MSVC 9, BeOS. $(Q#@(B printf of $B!F(Blong double$B!G(B numbers is unsupported on some platforms: mingw, MSVC 9, BeOS. $(Q#@(B printf "%f", "%e", "%g" of Infinity and NaN yields an incorrect result on some platforms: AIX 5.2, OSF/1 5.1, Solaris 11 2010-11, mingw, MSVC 9. $(Q#@(B This function does not support the $B!F(Ba$B!G(B and $B!F(BA$B!G(B directives on some platforms: glibc-2.3.6, MacOS X 10.5, NetBSD 5.0, OpenBSD 4.0, AIX 5.2, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11 2010-11, Cygwin 1.5.x, mingw, MSVC 9, BeOS. $(Q#@(B This function does not support the $B!F(BF$B!G(B directive on some platforms: NetBSD 3.0, AIX 5.1, HP-UX 11.23, IRIX 6.5, OSF/1 5.1, Solaris 9, Cygwin 1.5.x, mingw, MSVC 9, BeOS. $(Q#@(B This function does not support the $B!F(Bn$B!G(B directive on some platforms: MSVC 9. $(Q#@(B This function does not support the $B!F(Bls$B!G(B directive on some platforms: OpenBSD 4.0, IRIX 6.5, Solaris 2.6, Cygwin 1.5.x, Haiku. $(Q#@(B This function does not support precisions in the $B!F(Bls$B!G(B directive correctly on some platforms: Solaris 11 2010-11. $(Q#@(B This function does not support format directives that access arguments in an arbitrary order, such as "%2$s", on some platforms: NetBSD 3.0, mingw, MSVC 9, BeOS. $(Q#@(B This function doesn$B!G(Bt support the $B!G(B flag on some platforms: NetBSD 3.0, Cygwin 1.5.24, mingw, MSVC 9. $(Q#@(B This function behaves incorrectly when a $B!F(B-$B!G(B flag and a negative width are specified together, on some platforms: HP-UX 10.20. $(Q#@(B printf "%010f" of NaN and Infinity yields an incorrect result (padded with zeroes) on some platforms: MacOS X 10.5, FreeBSD 6.0, NetBSD 5.0, AIX 5.2, IRIX 6.5, OSF/1 5.1, Solaris 11 2010-11, Cygwin 1.5.x, mingw, MSVC 9. $(Q#@(B This function does not support precisions larger than 512 or 1024 in integer, floating-point and pointer output on some platforms: AIX 7.1, Solaris 10/x86, mingw, MSVC 9, BeOS. $(Q#@(B This function mishandles large floating point precisions (for example, formatting 1.0 with $B!F(B"%.511f"$B!G(B) on some platforms: Solaris 10. $(Q#@(B This function can crash in out-of-memory conditions on some platforms: MacOS X 10.3, FreeBSD 6.0, NetBSD 5.0.
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel