subsurface.git/scripts, branch v4.8.4

MXE: respect an MXE build type already defined

2018-11-14T09:06:10Z

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

build-system: switch back to upstream qt-android-cmake

2018-10-27T14:38:39Z

And in the process use our script to do the work. Signed-off-by: Dirk Hohndel

Fix after_success.sh for windows container build

2018-10-15T10:35:14Z

Ooops. Forgot to fix this before sent the patches, as this part doesn't works on my travis builds. Signed-off-by: Salvador Cuñat

windows-container: enable smtk2ssrf building

2018-10-15T10:35:14Z

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

Travis: build Subsurface-mobile against Qt57 as well

2018-10-09T17:03:38Z

Simply adding another OS / environment on which we test building of Subsurface-mobile Signed-off-by: Dirk Hohndel

Travis: build Subsurface-mobile on macOS

2018-10-09T17:03:38Z

Signed-off-by: Dirk Hohndel

macOS: check for system headers in SDK

2018-10-08T22:34:16Z

Starting with Xcode 10, system headers are located inside the macOS SDK. Add this location to the check for command line tools. Signed-off-by: Murillo Bernardes

Travis: don't upload the MXE Subsurface binaries

2018-10-07T21:00:45Z

More specifically, don't upload them from the old Windows build - we just keep that one around for the smtk2ssrf binaries. The Subsurface binaries are now created in the container based Windows build. Signed-off-by: Dirk Hohndel

Travis: build old style Windows without FTDI support

2018-10-07T21:00:45Z

This way we can still get an smtk2ssrf build until that is added to the windows-container target. Signed-off-by: Dirk Hohndel

Travis: add Windows build in a container

2018-10-07T21:00:45Z

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