Alexandre Julliard wrote:
Well, I don't like it much, but I haven't had time to look into a better solution yet. Basically I think it's dangerous to check for the file name with an absolute path and then include it with a relative path, since there is no guarantee we'll get the same file. I think we should really find a way to check that #include <freetype/freetype.h> works given the right C flags. Also I'm not sure about the portability of the ${FREETYPEINCL#-I} construct.
I see your point. Now that I think about it, I probably would have been bitten by it if anyone will. I run Red Hat 7.1 which has:
/usr/include/freetype/freetype.h (from FreeType 1.x) /usr/include/freetype2/freetype/freetype.h (from FreeType 2.x)
I just checked the gcc documentation, and directories specified with '-I' options on the command line are checked first. I have no idea, however, if other compilers behave in a similar manner.
Using absolute paths for the FreeType headers would be non-trivial, but probably doable. We would have to use autoconf to define macros that include the complete path name of the headers we want to include; then #include those macros instead of the file names. Somehow, I don't think you're going to want to do that.
One thing to keep in mind, however. The FreeType headers themselves use relative paths to include one another, so this is an issue that we're not going to be able to completely eliminate. This is why I had to mess around with the C_INCLUDE_PATH variable; AC_CHECK_HEADER tries to preprocess the header file, so it has to be able to find any subsidiary headers. (Is this what you mean by finding a way to check that #include <freetype/freetype.h> works?)
I also had the same thought about the ${FREETYPEINCL#-I} construct. According to
http://www.opengroup.org/onlinepubs/7908799/xcu/chap2.html#tag_001_006_002
it seems to be OK.
Frankly, I share your distaste for this whole mess.
-
Ian Pilcher