<div dir="ltr"><div dir="ltr"><div dir="ltr">Hmm,<div><br></div><div>Started to look at updating the container. But I am hitting some issues trying to run with a locally built version of the official container. </div><div>Do you know what version of MXE the container on github was generated from in case I need to chop to see where the failure comes from?</div><div><br></div><div>My suspicion is that the problems are related to the version of CMake being used. MXE now seems to pull in 3.15 and the official container is  using 3.10</div><div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 22, 2020 at 4:29 PM Dirk Hohndel <<a href="mailto:dirk@hohndel.org" target="_blank">dirk@hohndel.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On May 22, 2020, at 8:11 AM, Paul Buxton via subsurface <<a href="mailto:subsurface@subsurface-divelog.org" target="_blank">subsurface@subsurface-divelog.org</a>> wrote:<br>
> <br>
> So before I make any pull requests that might break the builds, I just want to check I understand the way that the github build for windows operates now.<br>
> The mxe-dockerimage-stage1.yml detects changes to scripts/docker/mxe-build-container and the mxe workflows. Which will trigger a build of the container.<br>
> The container will pick up the version in this yaml file. When building that has finished it will trigger the stage 2 build which is based on the container created in stage 1.<br>
<br>
Correct. And frankly, that whole thing is bogus. If you'd rather just create and test a container locally, go ahead and test it locally and once it works let me know and we can update the container that we use to build the Windows binaries.<br>
<br>
The idea behind doing this on GitHub was solid. But the implementation is painfully slow and fragile. And worse, the resulting docker containers contain all intermediate layers - which generally is what you want, but which here creates a resulting container that is more than twice as big as it needs to be. Which strains GitHub's resources and slows down our tests. So for the other two containers (Android and AppImage) I have started to go back to building them locally. I still keep the Dockerfile in the source updated so that it matches what I build, but... yeah.<br>
<br>
> So If I make changes to the windows containers then I need to update the VERSION field in the stage1 yaml file to avoid inadvertently trashing the existing subsurface/mxe-build-container:1.0 <br>
> <br>
> Is this correct?<br>
<br>
That's correct.<br>
<br>
> Also the scripts in scripts/windows-container are effectively legacy, and presumably kept for people building locally?<br>
<br>
Also correct.<br>
<br>
Let me know if you have more questions and need pointers. I'm 8 hours behind you, so your afternoons / evenings are better for me :)<br>
<br>
/D<br>
<br>
</blockquote></div>