Difference between revisions of "SAC Shared Building Services"
Jump to navigation
Jump to search
| (5 intermediate revisions by 2 users not shown) | |||
| Line 11: | Line 11: | ||
* GeoServer was building binaries for windows - using their windows jenkins slavebot, but lost that | * 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 | * 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 | On Mac Side | ||
* QGIS builds there own | * QGIS builds there own | ||
| − | * bottle.download.osgeo.org | + | * 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. | ||
| Line 22: | Line 24: | ||
In order to get to that point we need to research the following | 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? | |
| − | |||
| − | |||
| − | |||
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
- 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?