I just installed kicad-nightly-r31042.82a1175d72-x86_64.exe and the Environment Variables are NAMED 6 but POINT TO 7.
I’m working through other issues, but I don’t yet notice this causes errors.
Win10, up to date.
GP
Seeing the same on Ubuntu. It’s just a environment name so shouldn’t cause any issues. Wonder if this was kept like this for script compatibility reasons?
“shouldn’t cause any issues.”
AFAICT, it does not cause issues. But I have not worked through other issues, so I can’t be sure. But …
If the name of the variable isn’t important, then I’d omit the number as it just causes me (at least) to think there is something different due to the S/W version.
Thoughts of a dry brain in a dry season. [T.S. Elliot]
GP
In my opinion the names of those environment variables should not have a version number at all because it creates a maintenance nightmare. Also, because they are not “real” / “global” environment variables, but only generated internally in kicad there is also no need to change the names each year.
Edit:
I created an issue for this.
2 Likes
Edit: I’ve changed my opinion. I’ll add a suggestion for handling this below in about 15 minutes.
I totally agree with paulvdh.
I think removing the version number should be accompanied by (or followed by) changing the name to avoid confusion with actual Environment Variables.
GP
Paul:
At least on Windows, KiCAD lets user environment variables OVERRIDE the private ones.
This might mean there is utility in keeping the release number in the name.
In this example I set two environment variables (one with and one without the version number). As you can see, they were changed.
I then removed the environment variables, restarted KiCAD (6.0.10), and they were back to the values before I manipulated the environment variables.
GP
No that’s exactly the headache. It happens on all platforms. The only platform that would actually use the environment variables are Linux.
We ultimately want to eliminate the system environment variable inheritance.
Given the short time to the end of January, I’d suggest that just changing the name to use ‘7’ in lieu of ‘6’ would be safest. There may well be users who use the override out there. Deleting a feature at the end of the cycle doesn’t allow enough time to determine the number of users who use the feature.
I didn’t understand why you say only Linux platform users would use the feature.
GP
Because setting environment variables on macOS and windows is cumbersome and not normal course of business ever for any application on those platforms.
Modifying env vars is more typical for Linux for reasons
I didn’t find it cumbersome, YMMV:
The first run of KiCAD used its default 3RD_PARTY location; the second run was overridden as expected; the third run was back to the default.
I worked in the Windows group at MSFT and although not common, the use of environment variables was not rare either. It certainly was not “not … ever for any application”.
I cannot speak about usage on the MACs.
Edit:
Here’s a simpler version (I’m not a PowerShell guru):
I’ll make a suggestion in a separate post in a few minutes.
GP
You just did something that 98% of KiCad users on Windows will not ever understand (which is fine). Hence why it’s rare 
After reconsideration, I make this suggestion. [Reasons follow.]
For 7.0.0 and following:
- Change the names to “7” to match the release and thereby allowing 6 and 7 to run with different values. This is particularly useful when there is a format change as I believe has happened between 6.x and 7.x.
For 8.0.x:
- Depreciate but support the existing mechanism. Issue a warning on startup?
- Also support named, command-line parameters. No version number in the names.
For 9.0.x:
- Drop support for the existing mechanism (Environment Variables).
I think it is too late to remove an existing 6.x feature after 7.0 RC1 has been made available.
So keep the existing handling of Environment Variables but with the names changed to “7”.
Using different names for different KiCAD versions allows handling of file formats that change with the releases. This applies to Environment Variables only, see below.
.
I believe the feature of being able to select libraries is very useful. Consider a firm that has two approved parts lists:
- Airborne-approved.
- Ground-approved.
This could be extended for customers (NASA vs. USAF vs. …) or other criteria.
.
Using command-line parameters seems like a simple and “least common denominator” approach for moving away from Environment Variables. Since they would be set in properties of icons (or in scripts), the UI is trivial after setup. There is no reason to have the names be version dependent, as separate icons or scripts would be used to invoke different versions and the version-appropriate location would be in the icon or script.
GP
I am not a KICad develeoper and I don’t know much about KiCad’s internals. I’m merely a user trying to help other users, and sometimes I report issues on gitlab when I discover bugs or when other users on this forum discover a “weird” issue with KiCad.
Can’t, this breaks all the libraries which have KICAD6 hardcoded in them…which is all of the footprints :3
It also breaks everyones existing design that uses those variables that got copied from the libraries.
Tis the pickle and why they are going to get yeeted at some point to avoid repeating the mess every release
I believe the feature of being able to select libraries is very useful. Consider a firm that has two approved parts lists:
Won’t work. The actual list of libraries is controlled by fp-lib-table. It’s not driven by the lib path var. In fact the lib path vars are merely for being to relocate the directory but the directory does not get scanned for inclusion or anything. Those fancy dual sets of library people can swap fp-lib-tables…or like any reasonable person, just have two sets of libraries with suffixes/prefixes.
30 years or so I used Ultiboard. That program had different “density classes”. There were libraries with “default” footprints, and there were libaries with smaller footprints for high density boards. There may also have been library differences for reflow and wave soldering.
Are those library classes still a thing? I think wave soldering of SMT parts is obsolete because it introduces too much thermal stress on the parts.
I don’t think manufacturers of mass produced disposable domestic products know this.
Many products (eg. 240VAC household led lamps, pop-up bread toasters, SMPS microwave ovens, etc.) still use single sided phenolic PCBs with a combination of THT and SMD components.
All very nasty and built to a price for a limited life.
Maybe someone should go and tell them then. 
Can’t, this breaks all the libraries which have KICAD6 hardcoded in them…which is all of the footprints :3
It also breaks everyones existing design that uses those variables that got copied from the libraries.
Wow. That’s FUBAR. Sad.
Given the footprints have the macro name in them, why was the ‘6’ put in the names in the first place?
GP
It’s annoying but not catastrophic, there’s a few easy fixes if you know what to do (3D models are missing in 3D viewer after updating to V6)
the versioned variables have the advantage of letting you install multiple library versions at the same time (one for v5, one for v6, one for v7…)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.