We built 64bit and 32bit binaries for quite a while, but anymore, so I think
those should be disabled.
Ironically, I used to simply spot-create a massive VM on AWS (think 64 cores
and many GB of RAM) which would then do the build fairly quickly and be
terminated afterwards. That made dealing with that build feasible.
I wonder if they would complete within the time limits in GitHub these days. A
few years ago they definitely did not.
I experimented with a two stage build, but that was just horrible to work with.
/D
On January 13, 2024 3:30:42 AM PST, "Salvador Cuñat" <salvador.cu...@gmail.com>
wrote:
>Hi Michael.
>
>El vie, 12 ene 2024 a las 2:32, Michael Keller (<mikel...@042.ch>) escribió:
>
>>
>> No problem, I can hold off on that until you let me know.
>>
>
>I've finally been able to build the image and works fine. Attached is the
>patch to apply taken from the github PR. I don't know too much about MXE's
>internals but the patch has passed all recommended tests from MXE site,
>downloads the correct tar file, correctly checks for version, and correctly
>checks file's checksum.
>
>BTW, I've noticed we are building the image with shared libraries for both
>triplets x86_64-w64-mingw32 and i686-w64-mingw32. But then we only use
>those from x86_64-w64-mingw32.
>
>i686-w64 binaries add approx. 3GB to the image and probably 1 hour to the
>build, depending on the machine, off course. Maybe @Dirk Hohndel
><d...@hohndel.org> remember why these are built or maybe they are just a
>dangling blast from the past ;-).
>
>If it's the last case, I think they can be safely removed from the image
>build.
>
>Best regards.
>
>Salva.
--
From my phone
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
