Discussion:
Subsurface and smtk2ssrf Windows builds
Dirk Hohndel
2018-10-08 15:01:32 UTC
Permalink
Salvador, everyone

I have switched the Windows test / build on Travis to a different model where I provide a docker image that has MXE pre-installed and that makes it easier to test things locally when encountering errors on Travis: simply run that same Docker image on your local machine.

The goal was to make sure that this is as easy as

sudo bash ./scripts/windows-container/before_install.sh
sudo bash ./scripts/windows-container/travisbuild.sh

This assumes that you have Docker installed and that you have a reasonably fast internet connection (as it downloads a ~2G docker image the first time you call it - after that it will have this cached locally).
The scripts end up creating a 'win32' folder in parallel to the Subsurface directory that you are in and also runs autoreconfig in the ./libdivecomputer directory in order to build things - all this runs as root, so it might be easier to simply keep a separate copy of your Subsurface sources for these Windows builds.
Under ../win32/subsurface you'll end up with a Subsurface Windows installer.

Right now I kept the old Windows environment on Travis as that is used to build smtk2ssrf - but I think it should be reasonably easy to integrate this with the container based solution that I have. Salvador, why does this have to be a static MXE build instead of a shared one? That duplicates a LOT of things and would make the MXE container significantly bigger...

And to everyone: this should allow you to build your own Windows installers for testing - and they should pretty much match what we ship to our users :-)

/D
Salvador Cuñat
2018-10-09 20:19:58 UTC
Permalink
Hi Dirk.
Post by Dirk Hohndel
Salvador, everyone
I have switched the Windows test / build on Travis to a different model where I provide a docker image that has MXE pre-installed and that makes it easier to test things locally when encountering errors on Travis: simply run that same Docker image on your local machine.
The goal was to make sure that this is as easy as
sudo bash ./scripts/windows-container/before_install.sh
sudo bash ./scripts/windows-container/travisbuild.sh
Why run sudoed? I'm running them as user and before_install.sh works
simply well.
BTW, the build script is failing, for me, to build grantlee,
googlemaps and subsurface itself; but doesn't seem sudo related.
Post by Dirk Hohndel
Right now I kept the old Windows environment on Travis as that is used to build smtk2ssrf - but I think it should be reasonably easy to integrate this with the container based solution that I have. Salvador, why does this have to be a static MXE build instead of a shared one? That duplicates a LOT of things and would make the MXE container significantly bigger...
Yes, it is easy to integrate; before_install.sh requires little
changes and travisbuild.sh just a parameter in the command line.
What seems impossible ATM is get a shared MXE build. The package is
listed only static in the build matrix in the mxe site. I'm going to
try going back in the mdbtools git tree but I don't have good
expectations.
I've built a tarball without mdbtools (68.7 Mb), but couldn't try it
yet because of the other failures.

Best regards.

Salva.
Dirk Hohndel
2018-10-09 21:42:50 UTC
Permalink
Post by Salvador Cuñat
Hi Dirk.
Post by Dirk Hohndel
Salvador, everyone
I have switched the Windows test / build on Travis to a different model where I provide a docker image that has MXE pre-installed and that makes it easier to test things locally when encountering errors on Travis: simply run that same Docker image on your local machine.
The goal was to make sure that this is as easy as
sudo bash ./scripts/windows-container/before_install.sh
sudo bash ./scripts/windows-container/travisbuild.sh
Why run sudoed? I'm running them as user and before_install.sh works
simply well.
Because on my system docker can only be run as root.
Post by Salvador Cuñat
BTW, the build script is failing, for me, to build grantlee,
googlemaps and subsurface itself; but doesn't seem sudo related.
I'd love to see the errors. This works locally for me and on Travis - and
one of the key attractions in this design was that because it's all inside
the container it should behave the same for everyone. So I wonder what's
going wrong.
Post by Salvador Cuñat
Post by Dirk Hohndel
Right now I kept the old Windows environment on Travis as that is used to build smtk2ssrf - but I think it should be reasonably easy to integrate this with the container based solution that I have. Salvador, why does this have to be a static MXE build instead of a shared one? That duplicates a LOT of things and would make the MXE container significantly bigger...
Yes, it is easy to integrate; before_install.sh requires little
changes and travisbuild.sh just a parameter in the command line.
What seems impossible ATM is get a shared MXE build. The package is
listed only static in the build matrix in the mxe site. I'm going to
try going back in the mdbtools git tree but I don't have good
expectations.
I had EXCELLENT success going to github.com/mxe/mxe and open issues.
People there tend to be quite responsive. Sometimes the answer is "doesn't
work because BLA", but a couple of times already I got them to upgrade
things or change configurations...
Post by Salvador Cuñat
I've built a tarball without mdbtools (68.7 Mb), but couldn't try it
yet because of the other failures.
Thanks for working on this!

/D

Loading...