subsurface/scripts/windows-container/in-container-build.sh

#!/bin/bash
# this gets executed inside the container when building a Windows
# installer on Travis
#
# working directory is assumed to be the directory including all the
# source directories (subsurface, googlemaps, etc)
# in order to be compatible with the assumed layout in the MXE script, we
# need to create the secondary build directory

set -x
set -e

mkdir -p win64
cd win64

# right now the container still has an older version of MXE installed
export MXEBUILDTYPE=x86_64-w64-mingw32.shared

bash -ex ../subsurface/packaging/windows/mxe-based-build.sh installer

bash -ex ../subsurface/packaging/windows/smtk2ssrf-mxe-build.sh -a -i
Travis: add Windows build in a container I expect this to become the default way to test Windows builds and create installers on Travis. The idea is that instead of downloading the pre-built MXE binaries we might as well use a container that has all this installed and can be used locally to test if things fail on Travis; which will allow us to have the exact same environment for testing locally as runs on Travis. At this point the container used is way too big - more effort needs to be spent on shrinking it. Right now this only deals with Subsurface and not with smtk2ssrf. Signed-off-by: Dirk Hohndel <dirk@hohndel.org> 2018-10-06 08:11:15 +00:00			`#!/bin/bash`
			`# this gets executed inside the container when building a Windows`
			`# installer on Travis`
			`#`
			`# working directory is assumed to be the directory including all the`
build-system: remove Grantlee references from legacy scripts I debated about this commit... we don't use these scripts any more, but it seems like it would be worse to leave the Grantlee references in them. Yet of course this is all no longer tested. Maybe it is time to delete the scripts from the tree. Signed-off-by: Dirk Hohndel <dirk@hohndel.org> 2020-10-07 19:46:06 +00:00			`# source directories (subsurface, googlemaps, etc)`
Travis: add Windows build in a container I expect this to become the default way to test Windows builds and create installers on Travis. The idea is that instead of downloading the pre-built MXE binaries we might as well use a container that has all this installed and can be used locally to test if things fail on Travis; which will allow us to have the exact same environment for testing locally as runs on Travis. At this point the container used is way too big - more effort needs to be spent on shrinking it. Right now this only deals with Subsurface and not with smtk2ssrf. Signed-off-by: Dirk Hohndel <dirk@hohndel.org> 2018-10-06 08:11:15 +00:00			`# in order to be compatible with the assumed layout in the MXE script, we`
			`# need to create the secondary build directory`

			`set -x`
			`set -e`

build-system: first steps towards a 64bit Windows build This is barely scratching the surface (no put intended), and of course the container needs to be updated, first, to have a 64bit version of MXE installed, but this seems to help make libmtp build correctly. Signed-off-by: Dirk Hohndel <dirk@hohndel.org> 2020-10-28 17:55:02 +00:00			`mkdir -p win64`
			`cd win64`
MXE: respect an MXE build type already defined And use that to have our Travis build still work with the existing MXE build container as well as the even older, pre-compiled MXE binaries used in the windows build. Signed-off-by: Dirk Hohndel <dirk@hohndel.org> 2018-11-14 09:03:08 +00:00
			`# right now the container still has an older version of MXE installed`
build-system: first steps towards a 64bit Windows build This is barely scratching the surface (no put intended), and of course the container needs to be updated, first, to have a 64bit version of MXE installed, but this seems to help make libmtp build correctly. Signed-off-by: Dirk Hohndel <dirk@hohndel.org> 2020-10-28 17:55:02 +00:00			`export MXEBUILDTYPE=x86_64-w64-mingw32.shared`
MXE: respect an MXE build type already defined And use that to have our Travis build still work with the existing MXE build container as well as the even older, pre-compiled MXE binaries used in the windows build. Signed-off-by: Dirk Hohndel <dirk@hohndel.org> 2018-11-14 09:03:08 +00:00
Travis: add Windows build in a container I expect this to become the default way to test Windows builds and create installers on Travis. The idea is that instead of downloading the pre-built MXE binaries we might as well use a container that has all this installed and can be used locally to test if things fail on Travis; which will allow us to have the exact same environment for testing locally as runs on Travis. At this point the container used is way too big - more effort needs to be spent on shrinking it. Right now this only deals with Subsurface and not with smtk2ssrf. Signed-off-by: Dirk Hohndel <dirk@hohndel.org> 2018-10-06 08:11:15 +00:00			`bash -ex ../subsurface/packaging/windows/mxe-based-build.sh installer`

windows-container: enable smtk2ssrf building Enable building of SmartTrak divelogs importer. A new, lighter, tarball for mxe static libraries has been built, as it seems impossible to build mdbtools with shared libraries (see mxe's build matrix). The tarball doesn't include prebuilt mdbtools and we build from source via build script. Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com> 2018-10-14 19:53:59 +00:00			`bash -ex ../subsurface/packaging/windows/smtk2ssrf-mxe-build.sh -a -i`