Re: [Pyobjc-dev] PyObjC & Python 2.4
Brought to you by:
ronaldoussoren
From: Ronald O. <ron...@ma...> - 2004-07-31 12:03:18
|
On 31-jul-04, at 12:45, Bob Ippolito wrote: > On Jul 31, 2004, at 4:07 AM, Ronald Oussoren wrote: > >> >> On 31-jul-04, at 0:19, Bob Ippolito wrote: >> >>> On Jul 30, 2004, at 5:02 PM, Ronald Oussoren wrote: >>> >>>> Hi all, >>>> >>>> I've just checked in two patches that make it possible to run the >>>> PyObjC unittests with Python2.4. >>>> >>>> One patch disables one unittests that tickles a bug in Carbon.CF >>>> (python bug 1000914), the other removes the call to >>>> pathForFramework in ScreenSaver/__init__.py. >>>> >>>> Could someone please explain why this call (and simular calls in >>>> other packages) are necessary? They look pretty useless. Likewise >>>> for the entire objc._dyld and objc._framework modules. >>> >>> They're not useless, they mimic the behavior of compile time linking >>> with dyld by respecting the dyld environment variables and using the >>> framework search paths. This allows you to load profile or >>> debugging versions of frameworks, use alternate frameworks by >>> setting the DYLD environment variables, etc. It also allows the >>> frameworks to be found by name only if they're not in the expected >>> location (or if the expected location is not given). >>> pathForFramework will also help with GNUstep portability by >>> providing an alternate implementation that uses the GNUstep root to >>> find frameworks and such. >>> >>> I don't understand why pathForFramework needed to be removed.. it >>> should return the input string for each case in the PyObjC source >>> code. Could you please show me a traceback or something? >>> >>> >>> from objc import pathForFramework >>> >>> pathForFramework('Foundation.framework') >>> '/System/Library/Frameworks/Foundation.framework' >>> >>> pathForFramework('SDL.framework') >>> '/Users/bob/Library/Frameworks/SDL.framework' >> >> That brings me to a new question: shouldn't >> '/System/Library/Frameworks' be stripped from all calls to >> pathForFramework in our wrapper modules? GNUstep definitely doesn't >> have frameworks at that location and the additional cost for >> searching the path should be neglectible. > > I thought about doing that, but since /System gets searched really > late I decided against it. Perhaps there should be a kwarg to > pathForFramework that says "this is a system framework", which would > search /System or GNUSTEP_ROOT (?) first. That's the other reason I > didn't bother; I don't really know enough about GNUstep to make it > work correctly there, so it wasn't worth changing something that might > possibly cause rare problems for OS X. Calling pathForFramework with an absolute path looks odd. I'd be *very* surprised if the function would ever return anything other that the argument in that case. E.g. os.path.isabs(path) should imply pathForFramework(path) == path. The only alternative is raising an exception when the framework doesn't exist. Changing these calls should not cause problems on OSX because we use bundle identifiers for most frameworks. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 |