[Qgis-developer] Build plugins for use with Mac binary

William Kyngesburye woklist at kyngchaos.com
Thu Jan 22 10:16:48 EST 2009

PS. Something occurred to me about distributing a plugin binary - Qgis  
isn't properly setup for 3rd-party plugins.  This requires (on OSX,  
but not necessarily other platforms):

- an external plugin dir, like in the user's home folder.  It's not a  
good idea to install 3rd-party plugins inside an application's bundle  
on OSX.  I don't know if Qgis has this option, but it's dependent on  
the next requirement.

- it can handle an arbitrary location for the Qgis application.  Users  
can and will move and/or rename the Qgis application.

This relocation flexibility has a couple parts:

- the plugin is compiled with the -bundle flag, which is true now

- the plugin does NOT reference any library inside the Qgis  
application package.  And there's the problem.  Normally, the -bundle  
flag gets around the problem of linking the main binary of a program  
(qgis) because that binary is assumed to be loaded already, but Qgis  
plugins also link the Qgis *libraries* and the Qt frameworks.

I'm not sure if the -bundle flag works for secondary linked libraries  
(ie qgiscore as linked from qgis), but I think it should.  It would be  
worth trying to compile your plugin by linking only GEOS and GDAL, no  
qgis or Qt, something like:

-bundle -undefined dynamic_lookup -framework GEOS -framework GDAL

This would also solve the problem of the incorrect library versions in  
the all-in-one build.

Heck, if we figure that qgis also loads the GEOS and GDAL libraries,  
you could also leave those out, then there wouldn't be the GEOS  
version problem.  You just have to assume that builds of Qgis will use  
the same GEOS and GDAL major versions, which could be dangerous.

(The safe way would be to compile separate plugin binaries for each  
Qgis distro.)

On Jan 21, 2009, at 2:25 PM, William Kyngesburye wrote:

> But really, it shouldn't matter what Qgis itself uses for extra  
> dependencies - external libraries or frameworks, or bundled.  And  
> it's not really up to Qgis to provide these itself (bundled).
> You can make your plugin with whatever dependencies you like,  
> independent of what Qgis uses.  You just need to make sure that they  
> are available somehow, either packaged with the plugin (or linked as  
> static libraries, which is good for oddball libraries), or in Qgis  
> (not recommended, except for Qt and Qgis libraries) or separately  
> (like my frameworks).
> Just build the plugin, ie with my frameworks, and don't change those  
> references, just the Qgis and Qt references.  Though there is  
> something wrong in the all-in-one build with the Qgis library  
> versions, which should be fixed for it to work at all.

William Kyngesburye <kyngchaos*at*kyngchaos*dot*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

More information about the Qgis-developer mailing list