Windows installation paths wrong

[Chris Elliott]

Installing v5 nightly (specifically kicad-r10532.7b7355772-x86_64.exe, version 5.0.0-rc2-160-g7b7355772) on a Win10x64 system that never had KiCad on it with the default installation settings results in invalid library paths.

The default installation settings has Environment variables NOT checked. (I recall this was the desired behavior in the kicad.info forums to not mess up customized installations.) When selecting "Configure Paths..." in the main KiCad project window I see that several paths start with "C:\msys64\mingw64\" instead of "C\Program Files\KiCad\". See the attached screenshot.

Predictably when trying to access any of those paths KiCad has problems.

I don't know if this is a packaging problem for Win10, or a build problem. Interestingly, the new template path is correct, but not the older library paths.

[David Pearce (halzia)]

Did you check the set environment variables box or is this what happens when nothing should be set?

[Chris Elliott (sembazuru)]

I did not check the box to set environment variables during install. I was just accepting the defaults as I would expect a new user to do. Just trying to see how a new installation goes for when the new users inevitably ask for help on kicad.info. Since KiCad had never been used on this machine there were no leftover environment variables to either muddy the waters or passively help things.

I was happy to see that the (schematic) library table was not only copied, but the user was given a choice of options with the default acceptable for a new user. (I didn't check to see what the requester would have said for the footprint library table.)

[Wayne Stambaugh (stambaughw)]

It appears that the windows installer is being built with CMAKE_INSTALL_PREFIX configured for /mingw64. This should only be configured when installing KiCad in your mingw environment. If CMAKE_INSTALL_PREFIX is not defined, it defaults to C:\Program Files which will result in the correct default install path in the windows installer.

[Chris Elliott (sembazuru)]

FWIW, the computer that I was trying to install on does not have mingw installed, and doesn't have a CMAKE_INSTALL_PREFIX environment variable.

As to the build, I downloaded the pre-built package from http://downloads.kicad-pcb.org/windows/nightly/ so I don't have any control over that.

I'll try to repeat my experiment sometime this week to see if the issue has been corrected w/o any comment here.

[Chris Elliott (sembazuru)]

I checked with today's nightly upload ( http://downloads.kicad-pcb.org/windows/nightly/kicad-r10576.01c2d93a8-x86_64.exe ) and still have the issue with the paths.

I originally incorrectly stated what type of system I'm using as an install target. It is a Win7 system (one of the lab computers at work). Again, this system has never (to my knowledge) had mingw installed on it so the C:\msys64 directory tree doesn't exist.

IMHO this packaging issue should probably be resolved before final v5 release.

_I_ know how to resolve this after installation, but I'm pretending to be a new user with no previous knowledge and installing with defaults. This will cause a lot of extra traffic on kicad.info if not outright turn off potential users.

[Wayne Stambaugh (stambaughw)]

CMAKE_INSTALL_PREFIX is not an environment variable. It is a build configuration setting that is being used when creating the windows build. By default, CMAKE_INSTALL_PREFIX is set to c:\Program Files by cmake (the configuration tool used to generate the KiCad build scripts). I'm not sure why our windows installer is built this way. Would our windows package developer please take a look at this and remove the -DCMAKE_INSTALL_PREFIX=/mingw32 setting from the build command? That should fix part of the problem. If the user chooses a different install path, than this will still be a problem. Given that most users install in the default path, it should be a relatively small issue.

[Chris Elliott (sembazuru)]

A thread on the kicad.info forum pointed to a related bug: https://bugs.launchpad.net/kicad/+bug/1775796

Apparently my searching skills in this bugtracker weren't good enough to find that one before submitting this one.

[Chris Elliott (sembazuru)]

Seems to be resolved as reported in bug report 1775796

Sorry, again, for the duplicate bug report.