Hi Bob, On Jan 26, 2006, at 10:55 PM, Bob Ippolito wrote:
[snip] >> Sorry, I wasn't really thinking about extensions. By Panther I did >> mean building against the 10.3.9 SDK, which would give the desired >> results for the Python binary itself, but as you said extending >> that to correctly build extensions that did the same thing would >> be a royal PITA. > > You still need to build against two different SDKs, which can't be > done with just compiler flags. You have to do two separate > compiles, and then lipo it together. At that point you might as > well use different compilers and target older versions of OS X. Yes, this was what I meant in my previous email about letting the SDK get specified at configure time. I was thinking to have bash script that automates the various steps. I guess you could put it into the configure script, but that does sound to me to be pretty painful. > The other thing is that Python's build probably detects a few > things at runtime, and at runtime it's seeing 10.4, so it might not > actually work on the target version of OS X. Yeah, if this is the case it'd be a real mess. ;-/ > Ideally all that stuff would be pushed to runtime checks, so that > it could choose a different code path based upon which APIs are > available... but first you have to isolate the instances where that > happens. > >>> I think the only approach that doesn't require hacking a >>> significant amount of Python's build process and distutils is to >>> have two Python installations, one x86 only and one PPC only. >>> For distribution, you would cook up some way to lipo it all >>> together. >> >> I can see how the issues with the strategy I outlined would be >> significant, but I don't see how Universal support on Tiger would >> be similarly difficult. Apple's Python 2.3.5 already is Universal, >> and I'm unaware of any issues with it (except that it doesn't >> build Universal extensions ;). The changes they made to the build >> process seemed to be fairly minimal. > > Yeah, a 10.4+ universal build wouldn't be too big of a deal because > you can do that with one invocation of GCC and one set of flags. > >> As far as distutils/working with extensions, I admit I'm not very >> familiar with that. I did notice when compiling wxPython though >> that there weren't any distutils flags passed to gcc that would >> conflict with the building of Universal binaries. The main >> question in my mind would be whether or not the built Universal >> extension libraries could be loaded by Python's dynamic library >> loader. If they can be loaded, and we could add the flags to >> distutils' default compiler/linker flags, what other major issues >> would need to be overcome? > > Some extensions aren't going to build cleanly universal, and most > users probably aren't going to have all the SDKs installed so if it > shipped with universal flags then it wouldn't be able to build > extensions. Unless we had distutils check for the existence of the Universal SDK before setting the flags, or probably more accurately, remove them if the SDK isn't available. Then perhaps add a distutils 'flag' to manually turn off Universal building for extensions that can't be fixed. This might be a bit of a hack, but I don't imagine it would be too painful. The question is how many extensions would have troubles... But I guess the only way we'll know is to test the waters. In any case, even if it wouldn't be reasonable to make a Universal build the "official" build, it would be very useful to people packaging apps, even if it were Tiger+ only. As far as the SDK dependency issue, IMHO, not everyone would need to build Universal - the key would be for distributors/packages to make Universal binaries, and I think it would be reasonable for us to tell them "have the 10.4u SDK and DevTools installed". (And maybe the Panther/Jaguar SDK assuming we could sort the issues you mentioned above out...) Again, assuming a Universal build does make a sensible default. Thanks, Kevin > -bob > _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
