[Qgis-developer] qgis 0.9 OSX build

[William Kyngesburye]

I have a Mac OS X build of Qgis 0.9.0 preview 2 available now.  In  
working out out how to bundle PyQt and SIP I used the @loader_path  
feature that was introduced in Tiger, so it won't run on Panther.   
Besides my frameworks, the only other extra software needed is Python  
2.5 (not the 2.3 that is in the system).

The Python support loads in Qgis, and I tested on the CLI by setting  
PYTHONPATH and importing qgis in python.

Also, I updated my Qt recently, so this uses Qt 4.3/PyQt 4.3 + SIP 4.7.

Some observations:

- there are some linking problems in the install step - msexport,  
qgis_help and the python qgis libs link to the source build copies of  
libqgis_core and libqgis_gui.  Probably an install_name_tool step was  
missed.

- the strange crash loading shapefiles when GRASS was missing seems  
to be fixed.

- python annoyance: Qgis uses Qt3support, core, gui, network, sql,  
svg, xml, so only those Qt frameworks would normally need to be  
bundled in the app.  But PyQt loads as a whole package, which means  
assistant, opengl, script and test also need to be bundled.

- python problem: since qgis python loads from the python executable,  
@executable_path won't work for the bundled Qt frameworks and pyqt -  
the frameworks can only have one install path (either relative to  
qgis or relative to python), and relative to python would be wrong  
and fragile, traversing across completely different directory trees.

So I ended up using Tiger's @loader_path feature.  That way they're  
all relative to each other inside the app bundle, independent of  
where python is or where Qgis is installed.  Only the executables use  
@executable_path.  Here is my diagram I came up with to map this out  
(I abbreviated a few things - @l and @x are loader_/executable_path,  
core and gui are the qgis libs):

-------------- next part --------------
# = done by install
bin
	msexport.app
		Contents
			MacOS
				msexport
					Qt* -> @x/../../../../lib/Qt*
					qgis_core -> @x/../../../../lib/
					qgis_gui -> @x/../../../../lib/
	qgis_help.app
		Contents
			MacOS
				qgis_help
					Qt* -> @x/../../../../lib/Qt*
					qgis_core -> @x/../../../../lib/
lib
	libqgis_core
		Qt* -> @l/Qt*
	libqgis_gui
		core -> @l/
		Qt* -> @l/Qt*
	libqgisgrass
		core -> @l/
		Qt* -> @l/Qt*
		grass
	lib* [externals]
	qgis [plugins]
		all
			core -> @l/../
			Qt* -> @l/../Qt*
		some
			gui -> @l/../
			externals [bundled] -> @l/../
	Qt*.framework
		Qt* -> @l/../../../Qt*

qgis [app]
	#core -> @x/lib/
	Qt* -> @x/lib/Qt*
	#gui -> @x/lib/
	libpq -> @x/lib/
share
	qgis
		python
			PyQt4
				Qt*.so
					Qt*.framework -> @l/../../../../lib/Qt*
			qgis
				core, gui
					core, gui ->  @l/../../../../lib/
					Qt*.framework -> @l/../../../../lib/Qt*
				
-------------- next part --------------


I wonder if bundling at least the Qt frameworks (and setting  
@loader_paths) should be part of the make install step?  Possibly  
even bundling the PyQt/SIP stuff?  I don't know about others, but I  
consider Qt to be one of those things you always bundle, and not  
leave in /Library/frameworks.  Things could go wrong in there -  
overwriting a user's version (older OR newer), or expecting a user to  
download and install it, C++ binary compatibility problems with  
different versions.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"We are at war with them. Neither in hatred nor revenge and with no  
particular pleasure I shall kill every ___ I can until the war is  
over. That is my duty."

"Don't you even hate 'em?"

"What good would it do if I did? If all the many millions of people  
of the allied nations devoted an entire year exclusively to hating  
the ____ it wouldn't kill one ___ nor shorten the war one day."

<Ha, ha> "And it might give 'em all stomach ulcers."

- Tarzan, on war