[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] Hide Carbon-dependency of ftmac.c ([ft] cannot open some
From: |
Sean McBride |
Subject: |
Re: [ft-devel] Hide Carbon-dependency of ftmac.c ([ft] cannot open some fonts on mac and linux) |
Date: |
Thu, 18 Oct 2007 13:47:54 -0400 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [ft-devel] Hide Carbon-dependency of ftmac.c ([ft] cannot open some fonts on mac and linux),
Sean McBride <=