Re: [Pyobjc-dev] buildapplication strawman

[<bb...@ma...>]

On Wednesday, November 20, 2002, at 08:32 AM, Jack Jansen wrote:
> On Wednesday, Nov 20, 2002, at 12:21 Europe/Amsterdam, tmk wrote:
>> That said, I trust the fact that Jack may have very good reasons to 
>> favor the framework install option instead. When you can spare the 
>> time Jack inquiring minds want to know :-)
> As I explained on the pythonmac-sig last month I'm not so sure 
> anymore, I would like to keep both options open for python 2.3, and 
> then we'll see which build catches on.

That's a dangerous game to play in the Mac and NeXT community that we 
have today... there are a lot of people that'll hang on to whatever 
they know for no good reason at all (myself included, at times :-).

> But when people thought I suggested doing away with framework builds 
> completely (which I didn't) there was quite a bit of protest. MacCVS 
> needs it, for using Python as its scripting language, and the Python 
> OSA component needs it.

Why do MacCVS and the OSA component need the framework build?  i.e. 
what is the specific dependency?  (I lurked throughout that 
conversation, but didn't catch specifics -- if you have URLs into the 
archive, that'd be great)

There is a middle ground -- don't build all of the python distribution 
as a framework build.  Simply stuff any resources that are mac specific 
into a bundle or framework that is installed into site-packages/ or 
<prefix>/lib/python<version>/plat-darwin/ and load 'em from that (thus 
also leveraging localization and other Bundle features).   The Mac 
specific modules could be built into the framework/bundle, as well, and 
could be dynamically loaded.   It could be done quite a number of 
ways...

> Note that a non-framework Python with a shared library seems like a 
> solution for this it's really only a poor substitute. With a shared 
> library approach your python installation cannot be moved around 
> anymore (Python itself can handle this, by using its own argv[0] to 
> locate the Lib folder, but embedding applications will always use the 
> fixed fallback path). Especially if we want binary installers things 
> shouldn't depend on a compile-time builtin pathname.

I'm not sure I understand.  Both frameworks and dylibs share the trait 
that they have the path to the library embedded in the dynamically 
loaded code...

[bumbox:~] bbum% otool -L /Library/Frameworks/PGPui.framework/PGPui
/Library/Frameworks/PGPui.framework/PGPui:
         /Library/Frameworks/PGPui.framework/Versions/A/PGPui 
(compatibility version 1.0.0, current version 1.0.0)
         /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 
(compatibility version 1.0.0, current version 8.0.0)
         /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
(compatibility version 2.0.0, current version 122.0.0)
         /Library/Frameworks/PGP.framework/Versions/A/PGP (compatibility 
version 1.0.0, current version 1.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, 
current version 60.2.0)

... and, as such, anything built against that framework will require 
that framework to always be in the spot as specified by the embedded 
path unless you play games with the DYLIB environment variables prior 
to launching the executable that requires the framework [as does 
python-bin-main to allow embedding of frameworks in the app wrapper].

b.bum