#13626: Allow for the use of built-in Python 2.5 in Leopard ------------------------------+--------------------------------------------- Reporter: mdickens@nd.edu | Owner: macports-tickets@lists.macosforge.org Type: enhancement | Status: closed Priority: Low | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Resolution: wontfix | Keywords: ------------------------------+--------------------------------------------- Comment (by mdickens@nd.edu): Replying to [comment:5 mww@macports.org]:
The framework build of Python is not required for anything. It is just that someone upstream decided that IF you want the pythonw wrapper (etc.) you HAVE TO build a framework. Unfortunately it is a pain to un-framework- ify Python, not clear how to set which architectures to build for (x86_64???) etc.;[[BR]] The problem is the mindboggingly configuration setup IF you enable the framework build. If you add ''-enable-framework'', you get hit by hard- coded stuff. If someone would mind fixing this, we could all be happy.
Is it your desire to allow for GUI-capable Python without the Framework? Why would one want to do that, when the Framework version works just fine the way it is? So what if the 'include's and 'lib's are installed in a 'strange' location ... Apple's GCC handles that just fine with the '-framework' flag. Why fix it if it ain't broke? In working on the latest python25 port tarball in ticket #11267, I think it is possible to create variants for doing 32-bit or 64-bit application / libraries (or both), using the "-arch" option in Apple's GCC. I believe that everything is controller by the top-level 'configure' script, which can easily be patched for different '-arch' types ... but this would then require +universal variant to work ... which requires some patches in Darwin 9 / OSX 10.5. -- Ticket URL: <http://trac.macosforge.org/projects/macports/ticket/13626#comment:7> MacPorts </projects/macports> Ports system for Mac OS