[ python-Bugs-856401 ] Definitive way to link to the correct Python.framework

[SourceForge.net]

Bugs item #856401, was opened at 2003-12-08 20:31
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856401&group_id=5470

Category: Macintosh
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: Definitive way to link to the correct Python.framework

Initial Comment:
The link target for Python should be specified by 
introspecting the Python framework itself and linking directly 
to the framework dylib, rather than using -framework and 
overriding the framework search path with -F.  Using -F may 
have undesirable side-effects.  

Example:  User has Python at /Library/Frameworks and 
wants to build an extension module that links to ~/Library/
Frameworks/FooFramework.framework.  User also has a /
Library/Frameworks/FooFramework.framework that they do 
not want to link against.

Solution:  Rather than -framework Python, Python should 
link directly to 
NSBundle.bundleWithIdentifier_('org.python.Python.framewor
k').executablePath().  Stock 10.3 has this located at:
u'/System/Library/Frameworks/Python.framework/Python'.  
The value of this is entirely dependent on the current running 
version of Python that the extension module will be linked 
against.  The dylib identifier will of course be expanded to 
the full /System/Library/Frameworks/Python.framework/
Versions/2.3/Python by the linker.

Caveats:  Example requires PyObjC, however these APIs are 
available in CoreFoundation's CFBundle and could easily be 
put into an extension module if PyObjC is not to be 
distributed with the next version of Python.  It will likely 
require a platform specific patch to distutils.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-12-09 14:11

Message:
Logged In: YES 
user_id=45365

Bob, I'm not convinced. First, the problem you sketch seems a bit 
academic (the user linking a Python extension against a 
framework for which one system-wide copy and one per-user copy 
exists), and there is a workaround too (the user adds another -F 
just before their own framework).

Second, I'm not convinced that "-framework Python" doesn't do 
more than just linking against the dylib inside the framework, or 
that it may do so in the future.

Finally, with the current distutils we cannot easily use introspection 
to get the real location of the framework that python is running 
from: distutils picks up this value from the Makefile LDSHARED 
variable, so the only thing we can do without distutils surgery is 
replace

LDSHARED=	$(CC) $(LDFLAGS) -bundle -Wl,-
F$(PYTHONFRAMEWORKPREFIX) -framework 
$(PYTHONFRAMEWORK)

with

LDSHARED=	$(CC) $(LDFLAGS) -bundle 
$(PYTHONFRAMEWORKINSTALLDIR)/$(PYTHONFRAMEWORK)

All in all I'm tempted to close this as "won't fix", but I'll give you 
another couple of days to convince me otherwise:-)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856401&group_id=5470