Is KICAD_CONFIG_HOME the only thing that matters?

I’m using a nightly. From this document, it appears the environment variable KICAD_CONFIG_HOME controls where KiCad looks for the sym-lib-table file, and that file determines where KiCad looks for the individual symbol library files. So all the KICAD_SYMBOL_DIR variable can really do is substitute its value into entries in the sym-lib-table file, but any environment variable could be used to do that. So KICAD_CONFIG_HOME is really the variable that’s in charge. Is this correct?

Also, if KICAD_CONFIG_HOME is not defined, then KiCad looks in a predefined place in the user’s home directory for the sym-lib-table file and, once again, KICAD_SYMBOL_DIR doesn’t really do shit. Is this correct?

Finally, if I have project-specific libraries, those are placed in a sym-lib-table file in my project directory, and this takes precedence if there is any overlap with the sym-lib-table file in my home directory. Is this correct?

Thanks for any illumination you can provide!

If it works the same way as with the fp-lib-table then the local table takes precedence. The deciding thing is the library nickname (defined in the table) not the file name.

There’s no “master” sym-lib-file. There are only two sym-lib-files, one global, one per-project. If you look into the sym-lib-file which is in the file mentioned in the Global tab of the dialog you can see there are directly those entries which you see in the dialog, no references to other sym-lib-tables. Therefore, when you install and start KiCad for the first time, you have some possibilities (for global table):

  1. The installer has already installed a sym-lib-table.
  2. You will populate the table yourself.
  3. A ready-made sym-lib-table is copied from a library.

You can’t have two libraries and have them both automatically or without tedious work in the global sym-lib-table.

If you install the libraries from git, you have to copy the sym-lib-table. Look into the table provided by the git library:

(sym_lib_table
(lib (name 4xxx)(type Legacy)(uri ${KICAD_SYMBOL_DIR}/4xxx.lib)(options “”)(descr “4xxx series symbols”))

So, your comment

was wrong, both factually and stylistically :slight_smile:

There was recently some developer discussion about letting each library have its own sym-lib-table and have them all in KiCad (if I understood it correctly). It has become more needed when 3rd party libraries (at least one) have emerged.

I tried to read again and understand how you understand these things and how I understand them. Let’s see…

Yes, but it’s the location of the whole configuration directory, where the global sym-lib-table and fp-lib-table must reside amongst other things.

Yes, the individual .lib files are listed in sym-lib-table.

The first part is correct. I hadn’t tested other environment variables, but now I did. And it really looks like you’re right: it’s possible to set an environment variable from outside and use it in sym-lib-table. KICAD_SYMBOL_DIR is handy because e.g. the sym-lib-table which comes with the git libraries can blindly rely on the existence (and hopefully correctness) of that variable.

It depends on what you mean by “in charge”.

Yes, KICAD_CONFIG_HOME just overrides the default config location of KiCad (and the default depends on the platform). The config dir should have sym-lib-table amongst other files.

Well, if KICAD_SYMBOL_DIR is used in the current sym-lib-table, then it does something, does it?

I think Rene already answered that.

Thanks for your answers! I think I have what I need.

I have updated the document mentioned in the first post. I already thought the document needs to include information about specific variables, but this thread was especially fascinating and gave some fresh ideas and made me finally to do it. You may read it to check if the ideas match your own. It’s still (heavily) under construction.

Hi @eelik et al.

Thanks for your document.

I’m currently running v4 on Windows, and it appears that several env variables are already defined in my system (like KISYSMOD or KISYS3DMOD among others) They are also defined in the kicad_common file located in the %APPDATA%\kicad directory.

When it will be released, I intend to install v5 side by side to v4, with the “new” libraries (for v5 only). I understand I will have to define KICAD_CONFIG_HOME to point to another config directory (probably %APPDATA%\kicad_v5), but as KISYSMOD or KISYS3DMOD are already defined in the system, don’t they interfere with v5 paths ?

In other words, what is the precedence between the definition in kicad_common and the variable defined in the system ?

The system variable (the real environment variable) overrides the one from kicad_common.

Yes, and that’s why you have to use a wrapper script or some other solution given in the document. That way the system-wide or user-specific variable values get overridden. Maybe this wasn’t clear in the document?

Wouldn’t the better way be to get rid of the registry entries and only use kicad_common file?

In this case, clearly yes. I will delete all the KiCad-related system env variables and create only a KICAD_CONFIG_HOME pointing to the v5 config directory. That should do the trick.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.