[QGIS-Developer] MacOS packaging

Denis Rouzaud denis.rouzaud at gmail.com
Fri Oct 26 08:56:30 PDT 2018

Hi Peter,

This is great news!

Le ven. 26 oct. 2018 à 11:26, Peter Petrik <
peter.petrik at lutraconsulting.co.uk> a écrit :

> Hello,
> we have been asked to create standalone QGIS package for MacOS. By
> standalone I mean that there will be a single package (.pkg) file that will
> be extracted to /Application folder and will contain all dependencies
> (GDAL, Python3, PyQT, Qt libraries, ...) and will be working without any
> additional installation steps (similar to any application you install via
> App Store).
> As there is no such open-sourced solution I could use or enhance, I
> started some prototyping here:
> https://github.com/lutraconsulting/qgis-mac-packager . I hope I can wrap
> the last bits next week and be able to produce QGIS 3.4 release and QGIS
> master nightlies on some Mac Cloud server. I used osgeo4mac homebrew for
> dependencies, since it looks like it is the most maintained package manager
> with osgeo libraries for MacOS. Usage of Conda packages could be better,
> but the number of downloads and the activity in any available repositories
> is not convincing.

Is Qt Mac Deploy of any help here?

> The aim is to eventually have QGIS bundled and shipped similar to Linux
> and Windows. Once we finish the work, we will send an email to the PSC and
> see if this is something they'd be happy to bring it under their umbrella.
> I am open to any suggestions or cooperation for either packaging or
> distribution. Feel free to
> write me PM or reply here. Thanks

I'd be happy to take part of the effort.

> Now its time to celebrate new QGIS release during weekend!
> Cheers,
> Peter
> Note: CMAKE scripts try to achieve similar tasks (qgis/mac/cmake/*.in).
> But it seems to me that only bundling of Qt libraries is actively
> maintained [QGIS_MACAPP_BUNDLE=1]and bundling of rest of libs (gdal,
> libzip, geos, etc.. ) [QGIS_MACAPP_BUNDLE=2 and 3] is not
> implemented/maintained. Also I am not convinced that CMake scripting
> language is best tool for such task. (due to reconfiguration on change,
> syntax/readability compared to python, tools available for path handling,
> ...)

CMake syntax is not really nice to read (maybe it's personal), but the
point is that all the logic is already written and accessible there, mainly
in terms of dependancy and library location.
I think it makes sense to try to keep the logic in a single place if
reasonably possible.

The QGIS_MACAPP_BUNDLE is indeed an non completed work from Larry. But as
pointed out, he's also working on something lately.

More generally speaking, and even though nothing is written in QGIS source
code yet, I think that this project is a very good candidate for a QEP.
Do you have any intention to do one?
Is the decision to go for Python and not CMake definitive for your project
or was it more a first quick try?

I hope my message did not sound too pessimistic. Moving towards a solution
to get a complete package for QGIS that is openly maintained in the
community is really great and I'm really glad you started this!



Denis Rouzaud
denis at opengis.ch  <denis at opengis.ch>
+41 76 370 21 22
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20181026/c2173b43/attachment.html>

More information about the QGIS-Developer mailing list