Content-type: multipart/related; boundary="Boundary_(ID_sjn7BMUS1ewzsZoRYwazig)"; type="text/html" --Boundary_(ID_sjn7BMUS1ewzsZoRYwazig) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT
>> :>>> import sysconfig
>> :>>> print sysconfig.get_config_var('USE_TOOLBOX_OBJECT_GLUE')
>> I'd expect that this prints None on your system, which is a configuration I haven't tested in a long while.
> It says 0, not None.
> In the python build procedure that we use here, I see that my configure line includes --disable-toolbox-glue --disable-framework --disable-universalsdk. At one point, all three of them were necessary to get a python that worked, but that choice of options is many years old and I'm not sure I ever knew why those are the options to use. I think it is partly because we don't want this python to try to go into /Library or whatever.
This is the problem. If I recompile python without --disable-toolbox-glue these things work:
- I can install pyobjc 2.2 with
- I can install pyobjc 2.3 with
easy_install --prefix ~/py pyobjc-core==2.3
easy_install --prefix ~/py pyobjc==2.3
I've come over to the belief that there are so many environment variation that it makes sense to explicitly check for prerequisites in the setup.py. For example, when I have C extensions, I call a function that confirms that Python.h is really present in the directory that Python says it is in. (Many linux distributions decide to make it part of a "development" package, so even though distutils will tell you where it is, the file isn't actually there.)
I can suggest something like:
if not sysconfig.get_config_var('USE_TOOLBOX_OBJECT_GLUE') :
print "pyobjc requires a python interpreter that was compiled with --enable-toolbox-glue"
sys.exit(1) # exit 1 so the build is recognized as failing
Thanks for all the help! I never would have had a solution otherwise.