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" <[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. 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 _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
