[PyQt] PyQt on OSX Snow Leopard notes

[Phil Thompson]

On Fri, 11 Sep 2009 10:00:39 -0500, William Kyngesburye
<woklist at kyngchaos.com> wrote:
> On Sep 11, 2009, at 8:57 AM, Phil Thompson wrote:
> 
>> On Fri, 4 Sep 2009 09:13:08 -0500, William Kyngesburye
>> <woklist at kyngchaos.com> wrote:
>>> For those trying this, here's what I found so far:
>>>
>>> - gcc compiles 64bit by default now, which will cause problems with
>>> the 32bit-only Qt (unless you are using Qt Cocoa).  Configure SIP
>>> universal so you get a 32bit SIP (the extra PPC code is harmless,
>>> except that PyQt will take longer to compile and be larger than
>>> necessary).  If you want 32bit-only or 32+64bit intel, you need to
>>> edit siputils.py and change the unicflags and unilflags lines
>>> appropriately.
>>>
>>> - the macx-g++ Qt mkspec is meant to run the current gcc version,
>>> which is now 4.2.  But there is also a specifically macx-g++42
>>> mkspec.  I figured macx-g++ should agree more with Qt, which was  
>>> built
>>> with gcc 4.0, so I edited it to run 4.0.  I don't know if it's really
>>> a problem anywhere down the line.  Maybe there should be a macx-g++40
>>> now.  But I don't know how to select a mkspec in the PyQt
>>> configuration (I haven't looked).
>>>
>>> - the python 2.6 executable is 32+64bit now, and will run 64bit by
>>> default. This is a problem with pyuic4, which is a shell script which
>>> runs a python script (with pythonw).  At first I thought to use the
>>> arch command in pyuic4 shell script to run pythonw in 32bit mode, but
>>> apparently the arch command is broken and pythonw would still run
>>> 64bit.  So I ended up creating a stripped copy of pythonw in /usr/
>>> local/bin with ditto:
>>>
>>> sudo ditto -arch i386 /usr/bin/pythonw2.6 /usr/local/bin/pythonw32
>>>
>>> and running that from the pyuic4 script.  If any of your PyQt-based
>>> applications run from python, they'll have to use this also.  Unless,
>>> of course, you use Qt Cocoa and compile PyQt 64bits.
>>
>> Using Python v2.6.2 from python.org, and after recompiling Qt, then  
>> PyQt
>> builds as normal.
>>
> Because it's 32bit only.
> 
>> Until Qt properly supports Snow Leopard I think I'll leave things as  
>> they
>> are.
>>
> It's not so much a problem of Qt supporting Snow (yes, the mkspec  
> problem, but it seems to be minor), but supporting OSX 64bit, which  
> covers both Leopard AND Snow.  The standard Carbon-based Mac Qt will  
> never be 64bit.  Qt Cocoa is 64bit (I have yet to try it out).
> 
> And there is now the extra 64bit-ness of Python in Snow now, which  
> causes trouble with Python-based software.  People WILL update to Snow  
> and WILL (and have already) have problems compiling PyQt.
> 
> Since Qt Cocoa may take a while to be fully functional and in common  
> use, PtQt at least needs some way to deal with a 64bit Python  
> executable (use the arch command where python/pythonw executed when  
> built for Qt carbon).
> 
> Note: I just figured out the problem with the arch command.  It's not  
> broken.  There are 2 copies of the python and pythonw executables: in / 
> usr/bin and in the Python framework.  The /usr/bin exe's are not  
> symlinks to the framework, and have different file sizes.  For some  
> reason the /usr/bin exe's don't work with arch, but the framework  
> exe's do.  /usr/bin/python2.6 and /usr/bin/pythonw2.6 ARE symlinks to  
> the framework.

I've added a --arch option to SIP's configure.py. It may be specified any
number of times. PyQt's configure.py will also use the information.

I've added a --use-arch option to PyQt's configure.py to tell it to use
arch in the pyuic4 wrapper script. If there is a problem with
/usr/bin/python then you should run configure.py using /usr/bin/python2.6

The changes are in the current snapshots. Let me know if more needs to be
done.

Phil