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
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
Potentially fixed for next build. The joy of powershell 5.1 host variances
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.
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.
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.
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
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
Woops, I broke the msys2 installer, it should be fixed tommorrow
1 Like
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)
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)
As far as I remember there were compatibility issues with 64 bit and 32 bit builds, which all have been supported by ngspice.
I am considering switching to an exclusive 64 bit build, then the situation will become eased.
Of course there is a incompatibility issue but my point is you are both building and bundling 32-bit from 64-bit separately.
i.e. 32 and 64bit already have separate MSVC output folders and then your script outputs “ngspice32” and “ngspice64”.
So there is no need for “64” in the filenames at any point
1 Like
MSVC builds updated to OpenCascade 7.5 and ngspice 34
EDIT: ngspice 64 bit will have the “64” suffix removed in the next build as well
1 Like
Thanks all for this work to get MSVC running!
I had a nightly from early Feb installed on Win 10. I uninstalled it using the Control Panel, then installed the version below. Simple as that. A MS VC++ popup appeared briefly before install started, which seemed correct and reasonable.
When I launch Pcbnew preferences I see the following:
I then installed the latest nightly version and confirmed that there was no issue opening Pcbnew preferences.
MSVC build:
Application: KiCad PCB Editor
Version: (5.99.0-9276-gf1039dfb94), release build
Libraries:
wxWidgets 3.1.4
libcurl/7.74.0-DEV Schannel zlib/1.2.11
Platform: Windows 10 (build 19042), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
Date: Feb 22 2021 00:16:29
wxWidgets: 3.1.4 (wchar_t,STL containers)
Boost: 1.75.0
OCC: 7.5.0
Curl: 7.74.0-DEV
ngspice: 34
Compiler: Visual C++ 1928 without C++ ABI
Build settings:
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
KICAD_SCRIPTING_ACTION_MENU=ON
KICAD_USE_OCC=ON
KICAD_SPICE=ON
msys2 build:
Application: KiCad
Version: (5.99.0-9277-g959c2f18ab), release build
Libraries:
wxWidgets 3.0.5
libcurl/7.71.0 OpenSSL/1.1.1g (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.41.0Platform: Windows 10 (build 19042), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
Date: Feb 22 2021 09:58:18
wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.73.0
OCE: 6.9.1
Curl: 7.71.0
ngspice: 34
Compiler: GCC 10.2.0 with C++ ABI 1014Build settings:
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
KICAD_USE_OCE=ON
KICAD_SPICE=ON
That is a bug that just got fixed 6 hours ago in 959c2f18
1 Like
Ha! What a stroke of luck! Thanks, Jon. I’ll try the next MSVC build, then.
Edit: Confirmed the very latest MSVC build as of now does not have an issue opening the preferences.
The present version could, you were just limited by packages that still provided py27 support - almost useless as I really needed numpy 
as long as pip is bundled with the bundled python it should … ill d/l the msvc nightly now for my windows machine to see
2 Likes
Theoretically, please try it out and report bugs against it. Hopefully we can iron out the last things before a stable 6.0