Commit graph

5 commits

Author SHA1 Message Date
Dirk Hohndel
e9073a7570 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-30 12:24:36 -07:00
Dirk Hohndel
b40c8de35b 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-08 12:19:39 -07:00
Dirk Hohndel
15c7ee5db0 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 17:06:10 +08:00
Salvador Cuñat
faca48f2b6 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-15 06:35:14 -04:00
Dirk Hohndel
450f654063 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-07 14:00:45 -07:00