[Pythonmac-SIG] building universal binaries
Kevin Ollivier
kevino at theolliviers.com
Fri Jan 27 08:46:07 CET 2006
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
>
More information about the Pythonmac-SIG
mailing list