Re: [ft-devel] how to forbid to link public-but-unrecommended function in libfreetype.dylib?

[David Turner]

Hello mpsuzuki,

The trick is ugly, but it is pretty commonly done :-)

I would recommend the following though:

- don't protect the header files with #ifdef FT2_BUILD_LIBRARY,
  this ensures that no user will be tempted to defined the macro
  by hand just to get it to compile.

- at the start of src/base/ftmac.c, use #undef to undefine the
  macros.

Voila, keep up the goo work,

- David

On Thu, 12 Oct 2006 21:09:07 +0900, address@hidden said:
> Dear Sirs,
> 
> As I've written in previous post, for MacOSX, I want to replace
> Carbon-based MacOS font support by Carbon-free implementation.
> However, a few functions using MacOS specific legacy datatypes
> (like FSSpec which cannot handle long UTF-8 filename) in their
> arguments cannot be replaced. When freetype2 is built on modern
> MacOSX systems, using such functions is not recommended.
> On the other hand, the legacy systems like classic MacOS/m68k
> don't know modern datatypes, the functions using legacy datatypes
> are essential. (the binary executable format for classic MacOS:
> CEF cannot be mixed with Mach-O, thus, different framework for
> classic MacOS and MacOSX won't cause serious problem)
> 
> Due to this discontinuity, moving all of unrecommended functions
> to internal headers (regardless of the system) is not good idea.
> 
> Some Unix desktop applications on MacOSX using freetype2 are
> growing up bigger and bigger, and runtime testing before release
> is insufficient. Thus, runtime warning message is insufficient
> to notice "unrecommended function is used" to the developer.
> 
> So, I wish if I could forbid (or disturb) the functions in building
> phase of the problematic application. Of course, keeping the function
> available for runtime linker is important (to avoid users from
> "unresolved symbol" trouble). There's any standard method to issue
> an error in cc1, with meaningful informative message?
> 
> I tried a trick in attached patch. Possibly, even if the application
> uses unrecommended function, it will include header file which defines
> the function's interface. Thus, if I replace the unrecommended
> functions by uncompilable macro functions when building procedure
> is not for libfreetype, the building procedure of the application
> will be interrupted.
> 
> Also I insert undeclared variable array, so cc1 will issue an
> error including the variable name, so the variable name can be
> used to show some message to developer.
> 
> However, this trick is very very ugly. There's any better method?
> 
> 
> Regards,
> mpsuzuki
> 
> 
> --- freetype2/include/freetype/ftmac.h
> +++ freetype2/include/freetype/ftmac.h
> @@ -92,6 +92,11 @@
>                           FT_Face    *aface );
>  
>  
> +#if !defined(FT2_BUILD_LIBRARY)
> +#define        FT_GetFile_From_Mac_Name(a, b, c)       {
> FT_GetFile_From_Mac_Name_uses_obsolete_FSSpec[]; }
> +#define        FT_GetFile_From_Mac_ATS_Name(a, b, c)   {
> FT_GetFile_From_Mac_ATS_Name_uses_obsolete_FSSpec[]; }
> +#define        FT_New_Face_From_FSSpec(a, b, c)        {
> FT_New_Face_From_FSSpec_uses_obsolete_FSSpec[]; }
> +#else
>    /*************************************************************************/
>    /*                                                                    
>      */
>    /* <Function>                                                         
>      */
> @@ -175,6 +180,7 @@
>                             const FSSpec  *spec,
>                             FT_Long        face_index,
>                             FT_Face       *aface );
> +#endif
>  
>  
>    /*************************************************************************/
> 
> 
> 
> 
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/freetype-devel
- David Turner
- The FreeType Project  (www.freetype.org)