On Fri, 11 Sep 2009 10:00:39 -0500, William Kyngesburye <wokl...@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 >> <wokl...@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'm not convinced this is a PyQt problem - even though it affects PyQt users. If you are on a 64 bit system then you would expect to be building 64 binaries, ie. 64 bit Qt Cocoa, not 32 Qt Carbon. I assume that when Qt "properly" supports Snow Leopard then that would be the default on 64 bit systems. In which case the standard build process, and pyuic, will continue to work. The current problems seem to be due to Qt being slow to support Snow Leopard, or maybe just slow to make Cocoa the default. I don't think PyQt should be expected to work around this temporary situation. I'd change my mind if you were to say that the Cocoa support was flakey and people will be sticking with Qt Carbon for some time to come. Phil _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
