I run Windows 7 Home Basic (32bit), so I downloaded “kicad-5.1.2_1-i686.exe” (thanks to KiCad team).
Since about a decade, I used working with a rather very old version:
KiCad-2010-05-05-BZR2356-final-WinXP_full_with_components_doc_autoinstall.exe
I installed this old version in a separate folder “D:\KiCaD”.
Just to be very sure before installing the newest version, I like to ask:
After installing the new program, could I run the two versions as ‘separate’ programs?
For instance, after reading some other’s posts here, I noticed that it wasn’t just me who couldn’t decide what to do next after reading the actual entry warning/question of the installer. It says:
KiCad is already installed. Installing this package will overwrite existing files. Do you want to continue?
I wish it was:
KiCad is already installed. Installing this package will overwrite existing files if you will choose the same install location. Do you want to continue?
Your wish is well based, but it’s not the only problem. The old one probably uses the same configuration directory than the new one by default and the files probably aren’t completely compatible. You should start the newer one with a script which sets the environment variable KICAD_CONFIG_HOME. That way the configuration of the newer version goes to another directory and you can keep them completely separate.
For instance, the only script file I am familiar with is *.bat (of DOS) which I still using when necessary.
So, as you suggested, I will read about it first.
This is what I was able to learn from your tutorial about using two KiCad programs as separate ones.
In my case, I will need two bat files, as KiCad512.bat and BZR2356.bat
The KiCad512.bat could be:
set “KICAD_CONFIG_HOME=C:\Users\MyUserName\AppData\Roaming\kicad” && start /d “C:\Program Files\kicad\bin” kicad.exe
The BZR2356.bat could be:
set "KICAD_CONFIG_HOME= D:\KiCad\share” && start /d “D:\KiCad\bin” kicad.exe
Assuming that I will install the newest KiCad v5 at default location(s) and I will run one KiCad program at a time, I think “KiCad512.bat” (above) is enough.
But I wonder if my “BZR2356.bat” needs more lines to set some environment variables that my actual old version uses. I mean the variables which may be overwritten when I run KiCad v5 (after executing KiCad512.bat).
Only the newer versions of KiCAD recognize the KICAD_CONFIG_HOME envieroment variable, as such, your “old” KiCAD version will need to be installed on the standard path, the newest one will be installed somewhere else.
That’s true, only 5.0 and upwards use it, so you have to run any older version normally as if it were the only installed version and make a script file or a shortcut with the environment variable only for the newer version.
This can of course be done with two new versions, too, so that one (usually the most used one/the default one) is run normally and the other with the script.
EDIT: but it shouldn’t affect the installation location, only the configuration folder location.
With this strategy - old version as default, new version with the script - the new version doesn’t overwrite anything. You have to take care that you don’t run the newer KiCad without that script. When you run it with the script for the first time it will use the given configuration directory. Every other path variable will be created by KiCad internally and stored in the configuration. The variables don’t affect anything outside.
So, if I simply renamed the old “Kicad.exe” in my folder D:\KiCad\bin as “KiCad_.exe”, it could be executed directly (or via a shortcut) without the risk of interfering with the new files of KiCad v5.
Also, if the files of the new KiCad v5 are installed at default locations, only the shortcut which will likely be generated (on desktop) will be needed to launch V5.
Thank you in advance for any comment.
Edit: It seems I will also need to launch KiCad512.bat after installing V5 and before running it.
You don’t have to rename it. It’s found and recognized by the whole path anyways, anything with uses it must know the whole path first and it can’t be confused with another .exe with the same name.
Naturally you have to install this and its files to a custom location which is different than the location of the other version. It should be enough that the installation paths given in the installer (which were directly related to your original problem) are different. I’m not sure what you mean by “default locations”. When you give the path to the installer it installs all the files there. C:\Program Files etc. is the “default location” which the installer uses, but you can change it. On the other hand the installer can be said to be using that given location as the “default location”. Then you could move some files manually to a “non-default location”.
And, unfortunately, one more thing. It’s possible that you have real environment variables defined in Windows for KiCad. They may have been set by the old installer. If that’s the case you should set all path variables in the script which runs the newer version. That’s really unfortunate and confusing but the fact is at least v4 installer set Windows env variables, and whoever decided it does so by default didn’t think about consequences back then.
Naturally you have to install this and its files to a custom location which is different than the location of the other version. It should be enough that the installation paths given in the installer (which were directly related to your original problem) are different. I’m not sure what you mean by “default locations”. When you give the path to the installer it installs all the files there. C:\Program Files etc. is the “default location” which the installer uses, but you can change it. On the other hand the installer can be said to be using that given location as the “default location”. Then you could move some files manually to a “non-default location”.
I guess this is related to the location of the exe file and its related system ones.
What about the location of “data” as:
"C:\Users\MyUserName\AppData\Roaming\kicad”
Will the installer give the user the option to change it too?
This conversation is a bit confusing, it looks like we don’t speak same “language”.
The installer doesn’t install or write anything in your AppData folder. Only KiCad writes the configuration when it’s run for the first time. And that’s the whole point of the script: it gives the location of the configuration to KiCad so that it knows where the configuration files are. Then, when you run v5 for the first time (with the script) KiCad notices that there’s no configuration yet in that location and creates new configuration. It also tries to guess the other paths (library paths etc.) and writes them to the configuration. You can set the paths inside KiCad with the UI and they are stored in the configuration provided that there are no real environment variables set in Windows which define those paths.
Again, and to be as clear as possible: don’t touch the old KiCad version. Let it and its files and configuration be as they have been. Tweak only the new version. (The possible environment variables stored in Windows are the only exception - it could be best to remove them and then set them inside the old KiCad version for that version only.)
I guess you mean “inside the script (bat) which may be needed for the old KiCad version”.
For instance, I opened my Windows 7 “Environment Variables” dialog. There are two variables only; the path of TEMP and another for TMP.
I think it is time for me to install V5. And my KiCad512.bat will likely be:
set “KICAD_CONFIG_HOME=D:\KiCad512\Data” && start /d “D:\KiCad512\bin” kicad.exe
Actually I meant “with the KiCad’s own UI when it’s running”. As I said, it’s easier to leave the old version be as it was and run it as before. I’m not 100% sure about pre-4 versions but there should be a dialog there with which you can set the path variables. However, if you never run v5 without the startup script you don’t have to set anything in the old version - it works just like before. V5 should work fine with you simple script because no Windows env variables seem to be set.
If you do run v5 without the startup script it may write to configuration something which breaks the older version, and the new one tries to use the old libraries if it reads the old configuration. That won’t end up well.
Now when we know what you have I would say that you’re safe trying this:
Leave the old version exactly as it was and run it exactly as before.
Install the new version to a different location.
Write the short simple script for the new version.
Never run the new version without the script.
When you run the new version for the first time (with the script of course!) it tries to guess the library paths etc.
Check the paths (libraries etc.) from Preferences -> Configure Paths. They should point to the folder where this new version of KiCad is installed.
Open “Preferences -> Manage xxx Libraries” and check the “File:” path which is above the library list. It should point to KICAD_CONFIG_HOME.
If the all the paths seem to be correct you’re good to go.
But still one possible problem occured to my mind. The newer installation may overwrite the Windows Start menu items. I don’t have a solution for that unless you want to install the older version again to overwrite them the second time. If you’re not careful you could start the newer KiCad from the start menu thinking it’s the older version - and it could mess up you old configuration because it doesn’t run the newer version with the script.
In my case, instead of “Start menu”, I usually start the old KiCad.exe by a double-click on a *.pro located in a project folder. So, I guess, after installing V5, the association of the extension “pro” and my “D:\KiCad\bin\kicad.exe” will remain.if I will double click on *.pro, the old kicad.exe will be launched.
Now, I have to figure out how to launch a new pro of V5 (since there will be many V5 projects) with less effort and leave the double-click for the old version. Perhaps doing the reverse is better by associating “pro” to the V5 exe.
Added:
I hope that the “file” menu of V5 has a list of “Recent projects” links and its length could be increased if necessary (for most programs, the typical length is 10 entries).
