[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Freetype]2.0 release install problems on Unix systems
From: |
David Turner |
Subject: |
Re: [Freetype]2.0 release install problems on Unix systems |
Date: |
Fri, 10 Nov 2000 10:58:03 +0100 |
Hi Cesar,
> oh yes, i agree. the point is that i sincerely see very few
> applications intended to run in both 8+3 systems and unix that won't
> have literally tons of constructions like that one. i don't like it,
> but that's how it is, and one of the reasons why 8+3 systems are
> vanishing from the face of the earth. using `freetype2' for unix
> systems then makes things uniform (i know of *no* other package that
> has a "dot" on the include path, that's very weird) and is not a big
> deal for people wanting to write portable code between 8+3 and the
> rest of the world. i think its a good compromise... it benefits most
> of the people while not really doing any harm to the rest.
>
OK, there's one method I'm using in other projects. The rules are that:
- the location of public (and internal) header files is
always taken from macros in the source code. For example, you can
use code like:
#include FT_HEADER(freetype.h)
#include FT_CONFIG_HEADER(ftoption.h)
#include FT_INTERNAL_HEADER(ftobjs.h)
- the macro FT_HEADER is a shortcut, like:
#define FT_HEADER(x) FT_HEADER_PATH(FREETYPE_ROOT,x)
#define FT_CONFIG_HEADER(x) FT_HEADER_PATH(FREETYPE_CONFIG_ROOT,x)
#define FT_INTERNAL_HEADER(x)
FT_HEADER_PATH(FREETYPE_INTERNAL_ROOT,x)
- where FREETYPE_ROOT, FREETYPE_CONFIG_ROOT, FREETYPE_INTERNAL_ROOT are
defined by default as "freetype", "freetype/config", "freetype/internal"
- where FT_HEADER_PATH deals with FT_FLAT_COMPILE with something like:
#ifdef FT_FLAT_COMPILE
# define FT_HEADER_PATH(d,x) FT_STRINGIFY(x) /* to generate "x" */
#else
# define FT_HEADER_PATH(d,x) <d/x>
#endif
By the way, this is completely ANSI. The only compilation trouble I ever had
with this scheme were with Win32-LCC, as its pre-processor is hugely broken
regarding stringification and concatenation (i.e. '#' and '##' in macro
definitions). But actually, FT2 can't be compiled in debug mode with
this compiler anyway.. :-(
There are several advantages to this technique:
- we don't need to test FT_FLAT_COMPILE on any inclusion, as is currently
done.
- we can freely modify the FreeType 2 include hierarchy without changing the
sources (both library and applications)
- we can install in "usr/local/freetype2" instead of
"usr/local/freetype2/freetype"
without requiring additional include flags at compile time
However, the definitions of FT_HEADER, FT_HEADER_PATH, etc.. must be available
when an application #includes any public header file. I solve this like this
(it's not too elegant):
- put all definitions in a file named "ftbuild.h", for example. It contains
definitions like:
#ifndef FREETYPE_ROOT
# define FREETYPE_ROOT freetype2
#endif
#ifndef FREETYPE_CONFIG_ROOT
# define FREETYPE_CONFIG_ROOT FREETYPE_ROOT/config
#endif
#ifndef FREETYPE_INTERNAL_ROOT
# define FREETYPE_INTERNAL_ROOT FREETYPE_ROOT/internal
#endif
+ definitions of FT_HEADER_PATH, FT_HEADER, etc..
- by default, the file is placed in <freetype2/config/ftbuild.h>
- put, at the start of each include file:
#ifndef FT_BUILD_H
# define FT_BUILD_H <freetype2/config/ftbuild.h>
#endif
#include FT_BUILD_H
#include FT_HEADER(.....) // other includes..
- put, at the start of each C source file:
#include FT_BUILD_H
#include FT_HEADER(.....) // other includes
while taking care that FT_BUILD_H is correctly defined when compiling
the source files (that's easy to add to the build system by the way).
Now, if you're on a Dos system, where you would like to install everything
under "c:\libs\freetype\include":
- compile the library with FREETYPE_ROOT defined as
"c:/libs/freetype/include"
and FT_BUILD_H as "c:/libs/freetype/include/config/ftbuild.h". You'll
need to also compile the library with FREETYPE_ROOT and FT_BUILD_H
defined..
- or, write your own version of FT_BUILD_H, like "c:/libs/freetype/build.h",
then compile the library with FT_BUILD_H defined appropriately. Then
your application can be compiled with something like:
#ifdef _MSDOS_
# include "c:/libs/freetype/build.h"
#else
# include <freetype2/config/ftbuild.h>
#endif
#include FT_HEADER(freetype.h)
#include FT_HEADER(ftglyph.h)
#include FT_HEADER(ftcache.h)
...
and still be _somewhat_ portable..
On Unix, if your installation path is really weird, "freetype-config"
should be able to handle it by defininf FT_BUILD_H or FREETYPE_ROOT
appropriately..
By the way, this technique is currently used in a project that
is already 3 months old and that I have already tested with
lots of compilers without worries, so I guarantee you that
there isn't any booby trap in there..
We can introduce this "solution" rather smoothly. I mean that
"old" apps using #include <freetype/freetype.h> should still
be able to work.. and we can start publicizing that this
method is deprecated on the web site..
Meanwhile, there have been more than 200 downloads of the 2.0
release from the SourceForge site already; I don't have the FTP
logs yet but I suspect it's going to be hard to back-track
incompatible changes..
Any opinions on the subject ??
- David
PS: For more details on the way this technique can be implemented,
you can have a look at the source files for the upcoming "MLib"
available at:
http://cvs.freetype.org/cgi-bin/viewcvs.cgi/mlib/include/freetype/mlib/
look especially at the file "mlib.h".
by the way, the "MLib" is a sort of replacement for GLib that is
designed specifically for writing reliable system libraries. By
this I mean:
A - no static data at all
B - custom memory manager (a la FreeType)
C - the use of clean-up stacks and exceptions to ensure
_reliability_ without imposing _tons_ of error checks
(unlike FreeType !!)
D - simple object system (including reference counting)
For now, I'm gathering all non-font specific code from FT2
into this new library. My intent is to write FreeType Layout
later on top of it.
The code is still experimental and I expect to change it
greatly in the next few weeks. However, I'm already very
happy with some of its features, especially "C" as it
greatly simplifies code development, error detection
and handling, etc..
- Re: [Freetype]2.0 release install problems on Unix systems, (continued)
- Re: [Freetype]2.0 release install problems on Unix systems, Werner LEMBERG, 2000/11/09
- Re: [Freetype]2.0 release install problems on Unix systems, David Turner, 2000/11/09
- Re: [Freetype]2.0 release install problems on Unix systems, Werner LEMBERG, 2000/11/09
- Re: [Freetype]2.0 release install problems on Unix systems, Ramiro Estrugo, 2000/11/12
- [Freetype] Re: [Freetype]2.0 release install problems on Unix systems, ramiro, 2000/11/22
Re: [Freetype]2.0 release install problems on Unix systems, crusius, 2000/11/09
Re: [Freetype]2.0 release install problems on Unix systems, crusius, 2000/11/09
- Re: [Freetype]2.0 release install problems on Unix systems,
David Turner <=