So the change to CMake is in MXE, in fact I don't think we install cmake as a package in the container other than as part of MXE.
They updated it in October, and the version we are currently using in Subsurface is from June, so I think I will have to just take the head of MXE and work through the issues. Not a problem, it just would have been easier to be able to make the changes incrementally to fix problems one at a time :-) On Tue, 26 May 2020, 16:28 Dirk Hohndel, <d...@hohndel.org> wrote: > 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> wrote: > >> >> >> > On May 22, 2020, at 8:11 AM, Paul Buxton via subsurface < >> 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