[ft] Inconsistency between ftoption.h and generated binary

[SiegeLord]

Hello,

I have fetched a copy of freetype-2.8 source and issued these commands on OSX:

./configure --prefix /tmp/freetype
make install

The first command printed out the following at the end:

Library configuration:
  external zlib: yes (autoconf test)
  bzip2:         yes (autoconf test)
  libpng:        yes (libpng-config)
  harfbuzz:      no

After compilation, I observed that the resultant freetype binary links
to png, zlib and bzip2:

otool -L /tmp/freetype/lib/libfreetype.6.dylib
/tmp/freetype/lib/libfreetype.6.dylib:
    /tmp/freetype/lib/libfreetype.6.dylib (compatibility version
21.0.0, current version 21.0.0)
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
    /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current
version 1.0.5)
    /usr/local/opt/libpng/lib/libpng16.16.dylib (compatibility version
38.0.0, current version 38.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1213.0.0)

However, if I look at the corresponding ftoption.h, the options for
system zlib, png and zlib2 are commented out, leading to an
inconsistency.

I build libraries that link in freetype and I (thought I could) rely
on the macros in ftoption.h to determine how the freetype was
configured (for the purposes of linking zlib etc when linking to the
static library).

Is it a user error not to modify ftoption.h when building freetype
like that? Is the expectation that the library binary and the header
are consistent uncalled for (i.e. am I misusing the installed
ftoption.h to determine freetype's configuration)? As a point of
comparison, if I use the CMake build system, then the ftoption.h
that's installed actually does reflect the binary (because
CMakeLists.txt modifies it in response to its configuration).

Thanks for your guidance.