Re: [ft-devel] FreeType Amalgamation

[Werner LEMBERG]

> 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:

  $(address@hidden(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.
  $(address@hidden(B printf of $B!F(Blong double$B!G(B numbers is 
unsupported on some platforms:
    mingw, MSVC 9, BeOS.
  $(address@hidden(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.
  $(address@hidden(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.
  $(address@hidden(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.
  $(address@hidden(B This function does not support the $B!F(Bn$B!G(B 
directive on some
    platforms: MSVC 9.
  $(address@hidden(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.
  $(address@hidden(B This function does not support precisions in the 
$B!F(Bls$B!G(B directive
    correctly on some platforms: Solaris 11 2010-11.
  $(address@hidden(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.
  $(address@hidden(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.
  $(address@hidden(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.
  $(address@hidden(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.
  $(address@hidden(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.
  $(address@hidden(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.
  $(address@hidden(B This function can crash in out-of-memory conditions on 
some
    platforms: MacOS X 10.3, FreeBSD 6.0, NetBSD 5.0.