--with-next-framework very broken on OSX

[ebd80758-eb43-4a34-86bb-a2b2a2196e69]

BPO	420601
Nosy	@jackjansen

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = 'https://github.com/jackjansen' closed_at = created_at = labels = ['build'] title = '--with-next-framework very broken on OSX' updated_at = user = 'https://bugs.python.org/bbum' ``` bugs.python.org fields: ```python activity = actor = 'jackjansen' assignee = 'jackjansen' closed = True closed_date = None closer = None components = ['Build'] creation = creator = 'bbum' dependencies = [] files = [] hgrepos = [] issue_num = 420601 keywords = [] message_count = 3.0 messages = ['4616', '4617', '4618'] nosy_count = 2.0 nosy_names = ['jackjansen', 'bbum'] pr_nums = [] priority = 'normal' resolution = None stage = None status = 'closed' superseder = None type = None url = 'https://bugs.python.org/issue420601' versions = [] ```

[ebd80758-eb43-4a34-86bb-a2b2a2196e69]

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.

[jackjansen]

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.

[jackjansen]

Logged In: YES user_id=45365

This is fixed in the CVS tree (I hope:-).