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 <mfbernardes@gmail.com>
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 <dirk@hohndel.org>
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>
That qmake -query was added for debugging a long time ago.
Since the comment clearly indicate that the edit of the Makefile is only
for Travis, let's only do it when running on Travis.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It wasn't documented in the first place (magic first argument, anyone?).
This used to be available for quite a few of the dependency and had
somehow kept around only for Grantlee and Googlemaps. Let's just kill
this and be consistent for all dependencies.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In some Mac environments autotools somehow think that we have clock_gettime(),
even though it isn't supported. Somehow the previous workaround stopped working
as make ended up re-running ../configure and overwriting our change. This tries
to work around that problem.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Turns out that Jan found an issue with the latest Kirigami, so let's go back to
the known good one.
This reverts commit 17ec95e70c.
Suggested-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Turns out that Jan found an issue with the latest Kirigami, so let's go back to
the known good one.
This reverts commit 40766db459.
Suggested-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Update to the master of today, and no issues detected on mobile-on-desktop
and Android.
Only, the ugly border is back as the magic hack of 0b16b547ae failed
due to the patch file that errored. So that is fixed too.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Build systems that run from tar balls and not git fail to create valid
.appdata.xml This solves the problem for tar balls that we create for
OBS via our own make-package script. It doesn't solve the problem for
Arch or Gentoo who I believe take our tar files created via git archive.
One way to fix this would be to change the process by which I create
those tar files, I guess.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of editing appdata/subsurface.appdata.xml in place, switch to our usual
pattern of modifying a .in file and add the resulting file to .gitignore.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Use correct format, create script to update the version and release date in the
appdata.
[Dirk Hohndel: call said script during the build process]
Signed-off-by: Alexander Wilms <f.alexander.wilms@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Switching to GitHub as source for libzip means that we need to encode
the version number differently. Newer versions of libzip don't compile
cleanly on Android and this one seems new enough.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This also switches us to libzip's new official home on GitHub, and takes into
account that libzip no longer supports autotools and instead now is cmake
based.
Building against that, on my Mac build system, Subsurface once again correctly
opens DLD files downloaded from divelogs.de.
Fixes#1534
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Clearly something has changed here. When I first tried to use Homebrew on
Travis the update would take often so long that the build would time out. Now
it is nice and fast. So instead of wasting time with the cache let's just use
Homebrew directly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Doing that confuses the build setup and as a result the library isn't found at
runtime without some fixups.
Fixes#1469
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
But simply ignore when building outside of Travis.
Of course since we are building Android in a container, we need to first pass
the environment variable to the container...
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
These come originally from https://github.com/travis-ci/travis-build and are
available when running on Travis, but not when running inside a Docker
container on Travis as we do in order to build for Android.
The goal is to provide a quasi heart-beat on STDOUT during very long running
commands - without this the wget to download Qt often times out, so that's
where we are going to use this.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There are actually more datatypes in bash than just strings. One can for
example hold a list of strings in a list, and use that to keep track of
what we're expected to do.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
The previous code assumed everything was good to go if just the tar ball
was there, but if it wasn't unpacked, it all went sideways.
This makes it more robust and to actually handle that the tarball might
just be there.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
