Windows MSVC Builds (+Python 3.9 support) available

Community Developer Announcements
#1

Now introducing MSVC builds for testing.
This new packaging includes Python 3.9 support.

Additionally, we have wxWidgets 3.1 bundled which brings bug fixes and improvements such as improved high-dpi support

OpenCascade 7.4 is also bundled which brings some additional 3d model parsing bug fixes.

Note: Windows 7 is no longer supported by these KiCad builds due to Python both dropping support and switching to Windows 8.1+ APIs.

These builds operate just like the “msys2 nightly” otherwise. You are however required to uninstall the msys2 version of kicad first before you can install the msvc version. There is no loss of settings doing so.

Builds made be found here: https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/testing/ and are prefixed with kicad-msvc. Please use builds dated from February 12th and onwards

13 Likes
Post-v5 new features and development news
#2

Thanks to Mark, Nick, Simon, and everyone else who worked on this, it’s a great step forward to have these updated libraries. I encourage all of our Windows nightly build users who have been reporting bugs to switch to these builds and report any new problems you see (plus enjoy all the bug fixes that comes with switching to wx 3.1…)

6 Likes
#3

I’ll second @craftyjon here with my thanks to @marekr @nickoe and @GyrosGeier! For our Windows power users, this will be a great step as we can now utilize Windows lightweight threads, so high density boards and complex schematics should see a noticeable speed bump.

4 Likes
#4

I suggest putting this into anouncment thread :slight_smile:. I already enjoy having antialiasing in 3D viewer (wx3.1 fix ). Thank you all :slight_smile:

#5

If any people with the right permissions on the forum to do that see this, go ahead

1 Like
#6

ah, one more question: Will msvc builds replace msys2 builds, or will msys2 build will be upgraded to the same dependency versions as msvc has today (wx3.1)?

#7

The current plan is to replace msys2 with msvc for the official release builds if no problems are found. We will still support building KiCad on msys2, but the latest version of all dependencies might not be available.

2 Likes
#8

Some quick notes:

The installer required uninstalling the older msys 5.99 first. OK, no problem.

I used the lite installer. Because I knew the older 5.99 version was uninstalled I checked symbol and footprint libraries. They were downloaded. The installer stays in copying the fp-lib-table for a long time – not a big problem, but annoying and possibly confusing because it may look like it’s stuck there.

But the symbol libraries weren’t installed. That’s a big problem. Now I’ve got this in Program Files:

image
image1159×380 39.5 KB

Symbols were downloaded but not copied properly into the “library” folder. (BTW, why there’s still “modules” and “library” folders while they really should be symbols and footprints?)

#9

The lite installer issue isn’t a MSVC build. The lite installer really being hotglued onto the installer. It is very single threaded and performance sensitive. It’s not stuck at extracting the fp-lib-table but actually copying the files from the tmp file and then deleting the thousands of footprint files in the temporary extraction folder item by item which is slow on Windows. This part is pretty hotglued so making the message meaningful is tricky

#10

Fixed the symbols not loading for the lite installer, it seems to have been broken for some time, unrelated to MSVC. The 5.1.9 lite installer is also broken.

1 Like
#11

ngspice/xspice codemodels are not found by ngspice.

Current wrong location and name:

lib/analog64.cm
lib/digital64.cm
etc.

Working location and name:

lib/ngspice/analog.cm
lib/ngspice/digital.cm
etc.

1 Like
#12

Potentially fixed for next build. The joy of powershell 5.1 host variances

#13

Just tried to install latest nightly from the “nightly” folder (kicad-r20961.1608282a57-x86_64-lite), and the installer asks me to uninstall KiCad first.
Does it mean it’s msvc build and not msys2?
Or for some reason I can’t continue overwriting msys2 installs?

I wanted to hold back for the early reports on msvc (use 5.99 for selected production projects); but still continue upgrade to recent msys2.

#14

Again about ngspice:
After installing
kicad-msvc.r20960.55db1aa5f5-x86_64-lite.exe
on top of
kicad-msvc.r20956.25f621e880-x86_64.exe
the codemodels are now found in
/lib/ngspice
whch is correct.
However the file names are still not o.k.:
We have
analog64.cm
but Eeschema is looking for
analog.cm
Same with the other codemodels.

#15

Yes.

You can do this:

  • Uninstall the old msys installation.
  • Install msvc version to the default or some other folder (can be changed in the installer).
  • Install msys version to another folder.
  • Follow Running several KiCad versions on the same Windows machine as much as there’s need for running parallel installations of the same version.
#16

So how to distinguish msys2 and and msvc versions?
I thought the msvc are named like:
kicad-msvc.r20960.55db1aa5f5-x86_64-lite.exe

and without “msvc”, these are msys2 builds.
Now I’m not sure.

1 Like
#17

It seems the upstream maintainer has left ngspice wrongly adding “64” to the end of the codemodel names for msvc builds in the vcproj file outputs

1 Like
#18

Woops, I broke the msys2 installer, it should be fixed tommorrow

1 Like
#19

Well, I am the upstream maintainer.

Yes, and as a post-build-event we run a script named make-install-vngspice.bat (1.9 KB)

#20

Why not make the 64-bit build immediately output with the final name?

Otherwise I need to patch it in vcpkg (I cannot use that script as it is incompatible)