FreeType autoconf checks

Ian Pilcher ian.pilcher at home.com
Mon Jun 4 17:24:52 CDT 2001


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                                         ian.pilcher at home.com
========================================================================




More information about the wine-devel mailing list