Difference between revisions of "SAC Shared Building Services"

From OSGeo
Jump to navigation Jump to search
(Created page with "This page is to capture all the needs for Windows and Mac binary building All OSGeo Projects have a need for building binaries for Windows and Mac OSX. Since these platforms...")
 
 
(7 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
All OSGeo Projects have a need for building binaries for Windows and Mac OSX.
 
All OSGeo Projects have a need for building binaries for Windows and Mac OSX.
 
Since these platforms are proprietary and need extra licensing, there is a bit more needed to satisfy than for Linux systems.
 
Since these platforms are proprietary and need extra licensing, there is a bit more needed to satisfy than for Linux systems.
 +
 +
Right now each project kind of does their own thing and no position to easily share.
 +
 +
'''Current State'''
 +
 +
* OSGeo4W - builds QGIS and Grass binaries, largely funded by QGIS project at moment
 +
* GeoServer was building binaries for windows - using their windows jenkins slavebot, but lost that
 +
* PostGIS builds windows binaries for PostGIS and pgRouting and other PostGIS related extensions (ogr_fdw, pgpointcloud) using their windows jenkins bot
 +
* R Windows binary packages distributed by the Comprehensive R Archive Network (CRAN) using OSGeo software (chiefly PROJ, GDAL and GEOS) use custom built binaries compatible with the build train used by R and are static linked; at present both 32-bit and 64-bit binaries are deployed. Static linkage is used to avoid having to deploy a package manager for external software on which R packages depend, since CRAN as a package manager already supports over 15000 packages with three binary versions (devel, release, old release) for Windows and macOS.
 +
 +
On Mac Side
 +
* QGIS builds there own
 +
* bottle.download.osgeo.org Homebrew binary packages for a bunch of OSGeo projects
 +
* R macOS. CRAN packages for macOS are static linked to custom built binaries, using the build train used by R. Static linkage is used to avoid having to deploy a package manager for external software on which R packages depend, since CRAN as a package manager already supports over 15000 packages with three binary versions (devel, release, old release) for Windows and macOS.
 +
 +
 +
'''Future State'''
 +
 +
Ideally have a set of resources shared by current Windows/Mac Builders.  Costs funded via SAC budget.
 +
In order to get to that point we need to research the following
 +
 +
# Who are the interested parties and those willing to do the work of packaging?
 +
# What options do we have for supporting the need
 +
* Windows cloud hosters - Hetzer, Atlantic.net, Microsoft Azure, other hosters
 +
* CI:
 +
# https://circleci.com/build-environments/ (supports Windows and Mac)
 +
# https://www.appveyor.com/ (supports Windows and Mac)
 +
# GitHub package feature?
 +
 +
* Distribution - download.osgeo.org,  repo.osgeo.org (we could conceivably do windows/mac distribution here and replicate this to a cloud offering for redundancy repo.osgeo.org (is a nexus repository supporting deployment of maven, docker images, CPAN R packages, Nuget packages, yum, and apt )
 +
* Key Signing - OSGeo currently pays for and we'll need to discuss how these keys are shared
 +
 +
* How will we grant access to these resources?
 +
 +
 +
 +
 +
 +
[[Category:Infrastructure]]

Latest revision as of 05:29, 8 June 2020

This page is to capture all the needs for Windows and Mac binary building

All OSGeo Projects have a need for building binaries for Windows and Mac OSX. Since these platforms are proprietary and need extra licensing, there is a bit more needed to satisfy than for Linux systems.

Right now each project kind of does their own thing and no position to easily share.

Current State

  • OSGeo4W - builds QGIS and Grass binaries, largely funded by QGIS project at moment
  • GeoServer was building binaries for windows - using their windows jenkins slavebot, but lost that
  • PostGIS builds windows binaries for PostGIS and pgRouting and other PostGIS related extensions (ogr_fdw, pgpointcloud) using their windows jenkins bot
  • R Windows binary packages distributed by the Comprehensive R Archive Network (CRAN) using OSGeo software (chiefly PROJ, GDAL and GEOS) use custom built binaries compatible with the build train used by R and are static linked; at present both 32-bit and 64-bit binaries are deployed. Static linkage is used to avoid having to deploy a package manager for external software on which R packages depend, since CRAN as a package manager already supports over 15000 packages with three binary versions (devel, release, old release) for Windows and macOS.

On Mac Side

  • QGIS builds there own
  • bottle.download.osgeo.org Homebrew binary packages for a bunch of OSGeo projects
  • R macOS. CRAN packages for macOS are static linked to custom built binaries, using the build train used by R. Static linkage is used to avoid having to deploy a package manager for external software on which R packages depend, since CRAN as a package manager already supports over 15000 packages with three binary versions (devel, release, old release) for Windows and macOS.


Future State

Ideally have a set of resources shared by current Windows/Mac Builders. Costs funded via SAC budget. In order to get to that point we need to research the following

  1. Who are the interested parties and those willing to do the work of packaging?
  2. What options do we have for supporting the need
  • Windows cloud hosters - Hetzer, Atlantic.net, Microsoft Azure, other hosters
  • CI:
  1. https://circleci.com/build-environments/ (supports Windows and Mac)
  2. https://www.appveyor.com/ (supports Windows and Mac)
  3. GitHub package feature?
  • Distribution - download.osgeo.org, repo.osgeo.org (we could conceivably do windows/mac distribution here and replicate this to a cloud offering for redundancy repo.osgeo.org (is a nexus repository supporting deployment of maven, docker images, CPAN R packages, Nuget packages, yum, and apt )
  • Key Signing - OSGeo currently pays for and we'll need to discuss how these keys are shared
  • How will we grant access to these resources?