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'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 _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
