Re: [Freetype]2.0 release install problems on Unix systems

[David Turner]

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..