So the logic of why we were building the container from our source tree was in order to ensure that you can easily reproduce the outcome.
There is a small issue with that as Ubuntu might update some versions, but I'd be surprised if we saw a jump from 3.10 to 3.15. cmake is provided by the host OS (so Ubuntu in this case). Are you starting from the same base distribution? The MXE version is fixed as a specific SHA. And as I grep through the sources to refresh my memory where that's done I notice that the SHA doesn't appear to be in the source tree. How weird. I believe the last one that I used (based on the remnants of local builds) was 9f6b9c6f - but I need to dig some more to figure out why this isn't in the sources... /D > On May 26, 2020, at 12:41 AM, Paul Buxton <paulbuxton.m...@googlemail.com> > wrote: > > Hmm, > > 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. > 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? > > 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 > > On Fri, May 22, 2020 at 4:29 PM Dirk Hohndel <d...@hohndel.org > <mailto:d...@hohndel.org>> wrote: > > > > On May 22, 2020, at 8:11 AM, Paul Buxton via subsurface > > <subsurface@subsurface-divelog.org > > <mailto:subsurface@subsurface-divelog.org>> wrote: > > > > 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. > > 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. > > 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. > > 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. > > 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. > > > 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 > > > > Is this correct? > > That's correct. > > > Also the scripts in scripts/windows-container are effectively legacy, and > > presumably kept for people building locally? > > Also correct. > > 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 :) > > /D >
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
