#41 #include <ftglyph.h> finds FTGlyph.h from FTGL rather than from FT on case insensitive systems

[Mojca Miklavec]

See also:

• https://savannah.nongnu.org/bugs/?40972
• https://sft.its.cern.ch/jira/browse/ROOT-5773

On Mac OS X we have a problem that the code for including ftglyph.h from FreeType 2 (#include FT_GLYPH_H) which used to include

#include <freetype/ftglyph.h>

now acts as

#include <ftglyph.h>

which loads the wrong file (from the wrong library) on case-insensitive system like Mac OS X. In my case it loads $prefix/include/FTGL/FTGlyph.h instead of $prefix/include/freetype2/ftglyph.h. This started to be a problem after the release of FreeType version 2.5.1 which eliminated one level of hierarchy. They reduced the path include/freetype2/freetype to include/freetype2.

Given that FTGL depends on FreeType, it would be great if FTGL would make sure that no filename would conflict with FreeType.

[MichaelM]

Here's a patch that renames FTGL/FTGlyph.h to FTGLGlyph.h, which fixes the name clash on OSX. The rest of the patch fixes the build scripts to work with the new file.

I've been using this on Mavericks and Yosemite and it doesn't appear to break anything. At least, it shouldn't if people are including FTGL in the correct way in their code. Obviously there will be problems if people are directly including FTGlyph.h in their code.

The patch is also in this git repo:

https://github.com/MichaelMarner/FTGL-OSXFix

[Daniel Macks]

I think the actual bug is that ftgl.pc publishes -I${includedir}/FTGL in addition to -I${includedir}, even though the documentation and headers themselves all use <ftgl *.h=""> in the #include statements. That is, whever ftgl headers are desired, they are explicitly prefixed as such and accessed via ${includedir}, which avoids accidentally seeing non-ftgl ones. And whenever non-ftgl headers are desired, they are obviously not prefixed as such, so they are only seen accidentally via ${includedir}/FTGL, which I contend is published for no reason.</ftgl>