Re: [Freetype] Re: Summary of ANSI preprocessor trouble..

[David Turner]

Hello Again,

  I'm writing this from home, given that I've left
  the office a few hours ago..

  Just when I thought that we had found a "perfect bullet",
  I tested the build with Intel's C/C++ compiler. The latter
  complains that it is unable to:

    #include  FT_INTERNAL_FILE(internal.h)

  because it can't open the "file" "T2_JOINPATH(FT2_ROOT..."
  yes, the missing "F" seriously looks like a bug in the
  Intel Compiler. Depressing..

  In all cases, I am now convinced that there is no portable
  way to use a macro in #include that contains _indirect_
  macro substitutions.

  We are now faced with two choices:

    - in one hand, we simply go back to #include <freetype/...>
      and install the files in ../include/freetype2/freetype
      on Unix systems, using the "freetype-config" script
      to determine the correct "-I" flags (and others..)


    - on the other hand, we still support #include <ft2build.h>
      with macros, but we define them _directly_, with a definition
      that changes with the install, like:

          #define  FT_FREETYPE_H          <freetype/freetype.h>
          #define  FT_TYPES_H             <freetype/fttypes.h>
          #define  FT_INTERNAL_OBJECTS_H  <freetype/internal/ftobjs.h>
          etc..

       for the "default" version, and

          #define  FT_FREETYPE_H          <freetype2/freetype.h>
          #define  FT_TYPES_H             <freetype2/fttypes.h>
          #define  FT_INTERNAL_OBJECTS_H  <freetype2/internal/ftobjs.h>
          etc..

       for the "Unix" one (using an automatically generated
       <ft2build.h>).


  I'd like your opinions on the subject. I'm personnaly getting
  really tired of this whole affair, as minor as it may be, and
  strongly favor the first solution. After all, it's simple,
  it already works, and I'm sure that a few old Unix monkeys
  can learn a few new tricks ;-)

Any comments, ??

- David