There are some people in the user forum who have spent time with these v4->v5
problems, including me and Rene. The consensus about the environment variables
seems to be what Rene already said, that they should not (without explicit user
intervention) be set for the system, but from KiCad itself. Nick confirmed that
the current v5 installer won't set them by default. They are still a problem if
they have been set by v4 installer.
su 15. heinäk. 2018 klo 5.04 Strontium (strnty...@gmail.com) kirjoitti:
I honestly think each major revision of KiCad should be considered a NEW
program, installs to a new place has its configuration and libraries all
in a new location. Only Incremental updates 5.0 -> 5.1 should be
considered upgrades.
I agree. It's probable that many users will want to continue with v4 for old
projects but v5 for new, and in the future the same thing will be true for v5
vs. v6, because they break the file/project compatibility. But where the
compatibility is kept it's more likely to be considered as just an upgrade.
Kicad configuration isn't complex or onerous so if a user wants to bring
a Kicad4 config into Kicad5 or 6 or whatever, then they do that
themselves, otherwise after install Kicad5 is a fresh blank sheet with
no relationship to anything that happened on the users computer in
Kicad4. I am not familiar with the issues on Windows, but I would have
thought now this is mostly a packaging issue only??
I tried modifying the Windows installer, I only needed to replace some of "KiCad" strings
with "KiCad5" and it can install v5 alongside v4 independently. The only problem is the
configuration and the environment variables set by v4. They can be handled with a startup script.
See https://forum.kicad.info/t/does-v5-have-to-overwrite-on-install/11282 for some details.
I also agree if it can't work this way now on Windows, then its all a
bit late for V5, but maybe V6 can consider itself a new program distinct
from V5. This would also help with testing, because users could use V5
for daily work, but also easily install a V6 daily side by side.
All this could be done with the Windows installer, provided that a startup
script would be offered.
To make this all, at least the startup script, as simple as possible I would
suggest one (or three) small changes to KiCad (for 5.1, or even 5.0.1?). Add
command line options --config=/path/to/config and --ignore-env-vars. The former
is obvious and would override KICAD_CONFIG_HOME system environment variable.
The latter would make KiCad ignore all system environment variables and use the
current internal logic and the path settings UI instead. That way the old
variables could be left for v4 and the newer versions would be completely
independent if the command line switches were used. The command line switch for
the config path would be mostly for convenience. In Windows starting a program
with custom environment variables is tedious and error prone to write (see the
above mentioned thread). Command line switches are much easier.
It could also be possible to make --ignore-env-vars=true by default. Sharing
the environment variables would be a special case if the user wants that.
The general problem with using system environment variables is that they are
good for situations when there's only one version of a program on the system,
and/or several processes share the same variable values. Neither of them is
true for parallel installations of KiCad.
Eeli Kaikkonen
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
