Logged In: YES
user_id=139309
There's a lot of things to consider here, including but not limited to:
If building universal binaries that maintain compatibility with Mac OS X
10.3 (two SDK), you'll need to build i386 and ppc architectures
separately and lipo them together (might as well do ppc64 too).
If building universal binaries that maintain compatibility with Mac OS X
10.2 (two SDKs, and two compilers!), you'll need to build with GCC 3.3
on ppc and GCC 4.0 on i386 with entirely different CFLAGS/LDFLAGS/
MACOSX_DEPLOYMENT_TARGET than the i386 side of things (that's
scary).
Some modules aren't available for every arch. For example, psyco isn't
really useful except on i386. PyObjC, anything that links to Carbon, etc.
isn't going to compile on ppc64, etc. If the ".so" is there (i.e. universal
binaries for plugins) then the PyImport machinery will see it, try and
import it, and get a very nasty low-level dyld error. Either the PyImport
machinery should inherit code that checks for arch sanity, or there
should be separate naming conventions (.i386.so) or locations (site-
packages-ppc) for each arch!
Because of the previous consideration, there will have to be ways to tell
distutils which architectures you want to compile for.. perhaps just
native by default, but allow (multiple-?)SDK multiple-arch builds if
requested.
|