What happened to nightly msys builds?
Last build available is dated 4.03
MSVC is updated on a regular basis.
Does this mean MSVC become “mainsteam” and msys is phased out?
The msvc build will be the official one for v6. Msys build won’t be offered officially.
1 Like
But does it mean the they are already not updated on regular basis?
I was under the impression that quite recently MSVC was just ‘early testing’ phase, with the risk of having new issues (related to new build environment, and new libraries like wxwidgets, python) that need heavy testing.
MSYS build for some time become “predictable”. But if that’s over, I’ll have to switch over to MSVC (i wanted to do this later, as I actually started to use 5.99 for selected projects)
There seems to be some build error, so it hasn’t been intentionally dropped yet.
https://jenkins.simonrichter.eu/job/windows-kicad-msys2-pipeline/
But yes, I think it’s time to switch to MSVC. At this point they’re more likely to get attention than the MSYS builds.
1 Like
Basically, both are nightly builds for testing.
The msys2 build is a bit more predictable in the innards, so if you want to test new features with some stability, that is the way to go.
The MSVC build is getting a lot of attention now, but the tool framework works differently than on the other platforms (based on Windows CreateFiber() instead of Boost.Context) so there may be interesting problems.
We would like to ship V6 based on MSVC, so please do test there, but if you’re doing productive work with the new features, you might want to hold back a little.
AFAIK there is at least one massive memory leak in the MSVC binaries, so you might need to restart every few weeks. 
1 Like
Thank you for the details. Indeed, at the moment i ‘trusted’ V5.99 with my selected projects, I’d prefer to keep testing new features while have the enviroment as predictable as possible.
Seems I will keep staying with msys for a while, and then move on to MSVC when it will have its pecularities worked out.
That is supposedly fixed as of 5-Mar, so if you see it, please report
Fun fact, due to bad implementation, I yeeted win32 fibers and just threw in the assembly context implementation. There’s some royal rabbit holing in the COROUTINE architecture thats twisting my head more than I can fix the fiber implementation which was leaking out infinite virtual memory with win32 fibers. I can at least understand and correct the assembly implementation as needed without worrying about the rest of the twisted…thing.
Which is fixed with the above mentioned yeeting
Honestly, after throwing in the MSVC assembly, there’s an unfixed bug in the MSYS2 assembly that’s amazing it doesn’t crash immediately 
(Wrong offset for the fiber local pointer of the stack)
Well the msys2 builds should be fixed and up in a few hours.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.