Re: [Devel] #include hacks in freetype headers

[David Turner]

Hi Keith,

> 
> This is the form which my tools complain about; I guess I fail to
> understand why the header files are expected to be restructured so much
> that a -I compile line can't direct a fixed #include statement to the
> correct file.
>
We have several reasons to use macros for inclusion:

  - first of all, some people complained because they don't want to
    use an additional "-I" when FreeType 2 is installed, really..

  - they allow some redefinition/relocations in <ft2build.h>, this
    is especially important for the configuration header files, or
    system-specific ones. this is also possible, but more painful
    with -I switches..

    (e.g. we use a different FT_CONFIG_OPTIONS_H when compiling in
     "developer" mode)

  - we can't use #include <freetype2/xxxx> because of the infamous
    8.3 file naming rule, and <freetype/xxx> is already taken by
    FreeType 1.x on Unix installations.

    <freetype.2/xxxx> was proposed, but no major enthusiasm followed
    it.

  - the macros are more explicit than the real header filenames,
    i.e. <freetype/ftmm.h> is not as meaningul as FT_MULTIPLE_MASTER_H
    for the upcoming, I have names like "MLIB_CONFIG_OPTIONS_H" which
    are a lot more reasonable than the equivalent
    "<mlib/config/mconfopt.h>"

  - they allow compilation with all source files placed in a single
    directory, with minimal updates (to the place where the the
    macros are defined, instead of in each source file).

I wasn't really enthusiastic about using them at first, but I must
say that they're just too good right now :-)
 
> If there is some instance where the above construction is indeed needed,
> then I suggest the form:
> 
> #ifdef FT_BUILD_H
> #include FT_BUILD_H
> #else
> #include <freetype/config/ftbuild.h>
> #endif
> 
> would solve this problem while still accommodating more primitive tools.
>
Would something like the following work too ?

   #include FT_BUILD_H  /* @<freetype/config/ftbuild.h> */

this would result in much simpler, and readable, changes, while
still enforcing the use of macros for inclusion by client
applications.

I'd be surprised if "makedepend" would need much modifications
to support this pattern. (note the '@' before the header path)

We could also write a simple python script to update the comment
appropriately whenever this is needed in the FreeType sources..

Any advice ?

Regards,

- David

 
> address@hidden        XFree86 Core Team              SuSE, Inc.
> 
> _______________________________________________
> Devel mailing list
> address@hidden
> http://www.freetype.org/mailman/listinfo/devel