[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Devel] Patch for FreeType2 #include problems on Unix (2001-03-17)
From: |
David Turner |
Subject: |
Re: [Devel] Patch for FreeType2 #include problems on Unix (2001-03-17) |
Date: |
Tue, 20 Mar 2001 17:18:02 +0100 |
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