Difference between revisions of "SAC Shared Building Services"
Jump to navigation
Jump to search
(6 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. | ||
+ | |||
+ | |||
+ | '''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? | ||
+ | |||
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?