[Python-bugs-list] [ python-Bugs-420601 ] --with-next-framework very broken on OSX

[noreply@sourceforge.net]

Bugs item #420601, was updated on 2001-05-01 18:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420601&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Jack Jansen (jackjansen)
Summary: --with-next-framework very broken on OSX

Initial Comment:
This bug report is not going to have a lot of useful 
data;  mostly just to get it into the system to see if 
others may care (or already be working on it).

In any case, --with-next-frameworks is quite broken 
under OSX.   It may not even really be pertinent any 
longer, but I have yet to verify that [investigation 
commences soon].

- executes ranlib against the dylib which breaks on 
OSX

- doesn't actually build a framework at all, but 
installs a dynamically loadable library (which may 
actually be more appropriate, all things 
considered)

- fails to install the dylib or any of the other .so 
modules in the actual platform specific directory 
where one might expect.  Instead, they end up in 
the generic dylib directory, but the PYTHONPATH 
does not search that directory.

- python executable will not launch because the 
dylib cannot be found.   However, given that the 
python executable does not have any kind of path 
information for the dylib, I'm not sure it would find it 
even if the dylib were installed in a "more correct" 
place.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2001-05-12 13:37

Message:
Logged In: YES 
user_id=45365

I know next-to-nothing of OSX frameworks yet, so I asked Steve Majewski <sdm7g@Virginia.EDU>,
and he came up with the following bit. Any more insights are welcome.

Steve said:
 It's definitely badly broken for OSX, and my suggestion was (and is)
to make (eventually) building a framework a separate post-build step
with it's own script. I'm not sure if anything different has to be
done during the build as prep or not. I'm guessing not -- I think on
OSX it's mainly going to be a question of packaging -- sort of how
you bundle up the resources, etc. into MacPython. 
 I think the only question about ripping it out is whether it's needed
for Next or OpenStep  support and is anyone still using it? ( There 
REALLY ARE folks who are still using them, and occasionally complain
on *.advocacy that it's still better than OSX, etc. but do any of them
use Python? ) 

 What is the policy ? 

 If it's that if no one on python-dev wants to speak up and adopt a 
platform, out it goes -- then by all means, dump it. (Although you
might want to put out an "official" Last Call first.)  

 Has this come up before ? Is there a PEP ? 
 If not, maybe we should write up a "last call for platform savior" 
 process proposal.  

 I know there's a PEP on removing features -- I'll have to look at
it and see if it covers platforms. I do prefer having a policy 
(whatever it is) than doing it ad.hoc. for basically the same reasons
as having one on feature removal. 


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

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