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

[Sean McBride]

On 9/27/07 11:56 AM, address@hidden said:

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

So do I understand correctly that your proposed change is basically to
prevent developers from making a mistake?  In other words, if a
developer does not mix (a) and (b)-type freetype libraries then
everything is OK?  I'm trying to understand if this is a change that is
really needed in some situations, or if it is merely to help people that
don't really know what they are doing.  :)

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

Understood.

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

Well, I am not a freetype expert (I only use it indirectly through VTK),
but I am not enthusiastic about this change.  I think it complicates
things greatly and fear that maintainability will suffer.

Cheers,

--
____________________________________________________________
Sean McBride, B. Eng                 address@hidden
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada