Re: [ft-devel] Hide Carbon-dependency of ftmac.c ([ft] cannot open some fonts on mac and linux)

[mpsuzuki]

Hi,

# I dropped freetype list because this post is already too specific
# for developers.

On Wed, 26 Sep 2007 10:39:56 -0400
"Sean McBride" <address@hidden> wrote:
>On 9/22/07 6:32 PM, address@hidden said:
>>As a proof of his idea, I wrote a sample header file "ftmacdyn.h"
>>to replace Carbon-derived functions in ftmac.c by the function
>>pointers. By including ftmacdyn.h, ftmac.c is changed to resolve
>>the Carbon functions in runtime, without writing the code but
>>insersion a few initialization routines. libfreetype.dylib has
>>no explicit symbol reference to Carbon frameworks.
>>
>>I want to discuss with developers importing Unix applications
>>to Mac OS X, about the idea using such hook to remove the
>>explicit symbol reference of Mac OS specific frameworks.
>
>I don't understand what problem this is trying to solve.  Can someone
>summarise?  I can understand that some developers may not want to bring
>in Carbon dependency, but freetype already has a switch to turn off all
>the Carbon functions, is it not sufficient?

Yes, the background of the proposal takes the configuration
switch is insufficient. By the switch, there are 2 incompatible
libfreetype.dylib on Mac OS X: (a) without Carbon (b) with Carbon.
It seems that (b) is a superset of (a) and no confusion... it's
misunderstanding. If (b) is introduced into the system based
on (a), new dependency of Carbon framework makes the linker
confused. If the developer correctly replace freetype-config
and libfreetype.la correctly, the new dependency is reflected
automatically. But there are many softwares and developers don't
use them, they try to link -lfreetype only.

The patch is designed to hide the dependency of Carbon from
the eye of linker, not to make FreeType2 independent with
Carbon.

>But here are my thoughts anyway...
>
>- even with your changes, Carbon.h must still be included (for structure
>& type definitions, etc.)

Yes, my patch is not designed to hide the Carbon dependency
from the eye of cpp/cc1. But your pointing out is important,
to keep the compatibility of public header files. I have to
reconsider.

>- although you don't call Carbon functions explicitly, the code is still
>Mac-only

Yes, my patch is not designed to make libfreetype independent
with Carbon.

>- the code is much less readable and much less maintainable.

Yes, I agree, as I wrote in the post, I don't think the
developer of FreeType2 can maintain ftmacdyn.h manually.
I have to write automating system to generate it.
BTW, you want ftmacdyn.h to be easier for FreeType2 users
(who use FreeType2 as a component of their softwares)?
One of my anxiety is ftmacdyn.h is ugly hack by cpp, and
if there's incompatibility between ftmacdyn.h versus ftmac.c,
the error messages generated by cpp would be very very
difficult to understand.

>- the code uses private symbols (ex: ApplicationServicesVersionNumber)

OK, this must be fixed immediately.

>>* CPP feature: Current ftmacdyn.h uses C99 preprocessor macros
>>  (to handle variadic arguments). They are incompatible with
>>  "-ansi" option. The legacy C compiler of Mac OS X 10.0 (using
>>  precompiled header by default) cannot process it by default.
>
>_Nobody_ uses 10.0!  10.0 cannot play DVDs, 10.0 cannot burn CDs.  It
>was essentially a beta OS.  I strongly suggest that you target 10.2 as a
>minimum.  At their summer 2007 WWDC conference, Apple stated that 67% of
>the 22 million active Mac OS X users are using 10.4, 23% are using 10.3,
>and 10% are using 10.2 or older.

Ah, I think the generator of ftmacdyn.h should not include
variadic arguments, because it's incompatible with "-ansi"
(it's generally expected compiler option of FreeType2) primarily.
The difficulty for Mac OS X 10.0 compiler is the second reason.
Sorry for confusing you.

--

Anyway, thank you for comment, I have to propose ftmacdyn.h
generator and I will ask if it's easy for developers.

Regards,
mpsuzuki