Re: [Devel] Patch for FreeType2 #include problems on Unix (2001-03-17)

[David Turner]

Hi Anthony,

> 
> Hello,
> 
> I was playing with freetype2-current (2001-03-17) yesterday and today:
> 
>     IMHO, the current freetype2 source caters too much to broken
>     compilers that the Unix build suffers.
> 
>     After some tinkering, and after referring to David, Werner et al.'s
>     experiments (2000-12-12, 2000-12-13), I think that ftheader.h
>     doesn't need to be exactly the same across all platforms.
>

That's _precisely_ the idea. The content of "ftheader.h" should be
processed by the install script on Unix in order to replace the

   #define   ..... <freetype/....>

with the relevant directory. I'll make a short summary of the
situation:

  - some applications still adhere to the old convention by making
    things "the old way", i.e. directly including headers like:

         #include <freetype/freetype.h>
         #include <freetype/ftglyph.h>
         #include <freetype/ftcache.h>

    of course, they use "freetype-config" to determine that they
    should add "-I/usr/local/include/freetype2" to their include path
    at compile time


  - the new convention is to do:

         #include <ft2build.h>
         #include FT_FREETYPE_H
         #include FT_GLYPH_H
         #include FT_CACHE_H

    for the 2.0.2 release, we want to _not_ break source compatibility
    of old applications. For this, we do not change the installation of
    header files. Thus:

      - "freetype-config --cflags" still returns
"-I/usr/local/include/freetype2"
      - "ftheader.h" contains macro definitions in the
<freetype/xxxxx.h> format

    2.0.2 must be the occasion for application writers to be aware of
the new
    convention and change their source.


  - when FreeType 2.1 comes out, we change the installation directory.
I.e:

         - "ftheader.h" is processed at install time to replace lines
           like "<freetype/xxxxx.h>" with "<freetype2/xxxxx.h>"

         - "freetype-config --cflags" will return an empty string

         - "include/freetype/*" is copied to
"/usr/local/include/freetype2/*"

    Then, applications that have changed to the new convention won't
need a
    single change to adapt to the new installation path. And die-hard
Unixers
    will be happy to not require additional -I paths when compiling..

I thus perfectly agree with you, but I think it'd be wiser to wait for
version 2.1 to adopt it, unless you really think there is a big problem
here..

>     So, why don't we use "sed" in builds/unix/install.mk
>     to replace all instances of <freetype/{,config/,internal/}*.h>
>     with FT2_{PUBLIC,CONFIG,INTERNAL}_FILE(*.h), which would
>     expands to <freetype2/freetype/{,config/,internal/}*.h>
>     in freetype/config/ftheader.h and freetype/internal/internal.h
>     for Unix?  Isn't this what David and Werner wanted in the first place?
>     :-)
> 
Yep. Note that FT2_PUBLIC_FILE, etc.. have been removed this afternoon
from the CVS repository. They were legacy macros though I've been
surprised to see that FT_SOURCE_FILE were still used to compile
each component ??

I think that "ft2unix.h" should be left untouched, and unused, for
2.0.2

>     Since builds/unix/install.mk isn't run for other platforms,
>     this "hack" does not sacrifice cross-platform compatibility.
> 
>     It may also mean that "-I/usr/include/freetype2" is no longer mandatory.
>     But of course, any users who don't use "-I/usr/include/freetype2"
>     are digging a hole for themselves.
>     Afterall, Thou shalt always use `freetype-config --cflags`, right?  :-)
> 
>     This was related to http://bugs.debian.org/79951 reported
>     by Gordon Sandler and forwarded to freetype-devel a while ago.
> 
> Another fix is in builds/unix/ft2unix.h:
> 
>    Debian JP developer Takuo Kitame ran into problems and filed a
>    bug report (freetype2-current, 2001-03-12):
> 
>         http://bugs.debian.org/89363
> 
>    In a nutshell, FT2_PUBLIC_FILE, FT2_CONFIG_FILE and FT2_INTERNAL_FILE
>    are defined in both ft2unix.h (i.e. /usr/include/ft2build.h)
>    and freetype/config/ft2build.h (now freetype/config/ftheader.h).
> 
>    No, cpp doesn't like that, unless you use #undef first.
> 
>    Anyway, instead of using #undef, I made the following changes to
>    ft2unix.h:
> 
>      - Removed the FT2_{PUBLIC,CONFIG,INTERNAL}_FILE macros because
>        they are already defined in freetype/config/ftheader.h.
>      - Use FT2_ROOT instead.  Afterall, cpp on Unix is not broken.  ;-)
> 
>    Seems to work here.  :-)
> 
> Please examine the attached patch file and commit it to the CVS
> if appropriate.  (and run "cd builds/unix ; autoconf".)
>

I'll examine it. I have not started working on the Unix build. It
seems that Tom and Werner are active today to do that. I really want
to release this thing fast, because we're going to switch to a new
(and much simpler) build system.. (more on this after the release)

> I know that using "sed" to change ftheader.h and
> internal.h during install may seem "unorthodox", but it works!  :-)

it's not unorthodox, it's the way this whole mess is supposed to work
:-)

Regards,

- David