On 9/27/07 11:56 AM, [EMAIL PROTECTED] said: >On Wed, 26 Sep 2007 10:39:56 -0400 >"Sean McBride" <[EMAIL PROTECTED]> wrote: >>On 9/22/07 6:32 PM, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel