On Feb 5, 2006, at 6:48 AM, Ronald Oussoren wrote: > > On 5-feb-2006, at 7:46, Bob Ippolito wrote: > >> >> On Feb 3, 2006, at 12:10 PM, Bob Ippolito wrote: >> >>> I think the only things missing from my branch currently are: >>> >>> 1) 10.3.9 support >> >> I believe this is taken care of now that Ronald contributed the >> weak linking patch. > > If anyone wants support for 10.3.x with x <= 8 now would be the > right time to speak up and volunteer resources :-)
In py2app I should at least be able to give a good error dialog if the app is built with the fat build but the target OS isn't >= 10.3.9, so this isn't all that urgent... >>> 3) Revamped Mac/OSX/Dist scripts (probably should rewrite all >>> that in >>> Python and not hardcode everything) >> >> This isn't done yet, but what we have now is probably a fully >> usable universal Python. > > I'll work on this, I probably still know what needs to be done from > when I tried to build a Python 2.4.2 compatible package using this > script. The "only" thing that needs to be done is to change strings in these files during (or after I guess) frameworkinstall: OSX/Dist/resources/ReadMe.txt OSX/Dist/resources/Welcome.rtf OSX/PythonLauncher/PythonLauncher_app/Contents/Info.plist OSX/PythonLauncher/PythonLauncher_app/Contents/Resources/ factorySettings.plist OSXResources/framework/Info.plist OSXResources/framework/version.plist OSXResources/framework/InfoPlist.strings I was thinking it would be easiest to use string.Template to do this, with a dict populated mostly with distutils.sysconfig information but with a couple extra strings added such as the architectures supported, the full version, and the size of the package after installation. >>> This backwards incompatible change is mostly just a backport from >>> setuptools' pkg_resources module. >>> >>> $ python -c "from distutils.util import get_platform as p; print p >>> ()" >>> macosx-10.4.3-fat >> >> This output will now be: >> macosx-10.3-fat >> >> The version number is determined from MACOSX_DEPLOYMENT_TARGET (or >> CONFIGURE_MACOSX_DEPLOYMENT_TARGET). It's relatively safe to >> assume that modules compiled with this build will be compatible >> with Mac OS X 10.3.9 (as long as they don't use 10.4 specific >> features anyway). > > I'm not 100% sure I'm happy with this. You can now accidently > create binary packages that claim to run on 10.3 yet don't. But as > you say, this will likely affect only a very small number of > packages (PyObjC being one of those, that's on my TODO list already). The only way to check this would be to set MACOSX_MAX_VERSION_REQUIRED to 1030, but that would be bad too because then you couldn't write code that takes advantage of Mac OS X 10.4 features because you'd get a compile time error. In the setuptools branch of PyObjC the 10.3 and 10.4 specific modules are in separate distributions. We could simply set MACOSX_DEPLOYMENT_TARGET to 10.4 in the 10.4 setup.py and then it should build a package that claims 10.4. >> For modules that absolutely require 10.4 you can set the >> MACOSX_DEPLOYMENT_TARGET environment variable at build time (e.g. >> in setup.py) and then the package produced will have a different >> platform string. setuptools will need work if people actually do >> this, because it will need to know that a Mac OS X 10.4 user can >> use "macosx-10.3-fat" and "macosx-10.4-fat" packages. It's >> probably a better idea to just write all your code so that it uses >> weak symbols for anything that isn't in 10.3 and raises >> ImportError on initialization if it's not usable. > > Setuptools already contains code for this (using 10.3 packages on > 10.4) in pkg_resources.compatible_platforms for the stock python > distribution. That should also work with the python24-fat tree. The > only thing that would require work is accepting a cpu-specific > version if a fat package is not available. The only reason that > might be useful is stuf like psyco which is only available for one > of cpu-type. Well the way everything is setup, it's not going to be reasonable to build a package that claims to be specific to a given architecture using the universal Python. We'd need to have Yet Another Distutils Hack that takes the architecture list off of the command line or something and modifies the compiler/linker flags.. ick. We do still need to patch setuptools because distutils.util.get_platform() is going to say 10.3, so we'd need to insert the code that knows what the actual version of the OS is. I can't think of anything that only works on one architecture... even psyco has a C-based ivm that makes some smaller optimizations on non- x86 platforms... -bob _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
