My workplace has decided to adopt KiCAD as the standard EDA tool for our electronics projects, and we’re in the process of getting our projects set up. We’re using GIT as a SCM, with a single repository shared amongst multiple board designs with a structure as follows:
${ROOT}/: Root directory of project
libs/: Parts libraries (symbols & footprints)
magicsmoke/: Part library for the “magicsmoke” part
README.md: documentation on where the symbol came from, supplier information, etc.
magicsmoke.lib
magicsmoke.mod
magicsmoke.dcm
magicsmoke.kicad_mod
… etc for other parts
parts/: Our PCBA designs
project01/: a KiCAD project
project01.pro
… etc
Now, the challenge with this directory structure is that it defaults to absolute paths. We’ve got a contractor who’s come on board to help us with this, he’s running on Windows 10 (as that’s what he’s familiar with, he’s also new to git). I’m on Gentoo Linux. Our immediate manager is running on MacOS X.
We can add the libraries to our project paths, no problems, but the absolute path is a problem… if I do it, the path is going to be something like /home/me/work/projects/whatever/…, if my manager does it, it’ll look like /Users/him/work/projects/whatever/…, and if our contractor does it, it’ll be C:\Users\him\My Documents\projects\whatever\….
Through experiment, I found that I could reference things with ${KIPRJMOD}, so I could add ${KIPRJMOD}/../../libs/magicsmoke and get the “magicsmoke” part library in the schematic editor and PCB editor. I was able to create a design, save it, commit it to git, and my manager could open it up on his end and everything looked fine.
BUT there’ll be a lot of parts, and manually fiddling this will get old quickly. Two of us can simply run a sed script on the fp-lib-table and sym-lib-table I guess, but sed doesn’t ship with Windows.
Are there plans to allow KiCAD to configure these paths relative to ${KIPRJMOD} unless a given library is beneath ${KICAD_SYMBOL_DIR}?
@Rene_Poschl has written a great set the tutorials about library management in the FAQ section of the forum, the general idea is described here:
and the specific idea for a team setup would be this:
the basic idea is that each user would need to define the environment variables locally and on the repository use only the variable names for the paths.
Note that the FAQs were written for the current stable version of KiCAD (v5.1.x) it is probable that in this year the next KiCAD versions (v6 currently 5.99 for testing) will be released and there some point will be different.
Ahh okay, many thanks for those pointers… I take it though if we have to define custom environment variables, that this would imply selecting new libraries and adding them won’t automatically use those environment variables?
It’s the error-prone tedium of having to hand-massage the directory paths that I was trying to avoid.
Using ${KIPRJMOD}
and then stepping two directories up: /../../libs/magicsmoke feels like the wrong approach to me.
Those libraries are (apparently) not specific to that project, and therefore the project home should not be used.
I would just make a new environment variable for the base directory of the libraries. I have done so in the past for datasheets. I have made a KIDATASHEET variable in: Project Manager / Preferences / Configure Paths
I agree. I have used this kind of relative path, but understood that it’s not the best solution. You will be forced to copy the hole directory structure as is, both libraries and projects, if you want to for example move the projects to another machine. If you want to move the libraries to another relative location you have to edit the paths in every project. It’s more flexible to use a dedicated environment variable for the libraries. Then the relative location doesn’t have to be kept forever.
If there is a path variable setup in kicad and the path of the new library you want to add is inside this path then kicad will automatically substitute the path variable to the path for the library tables.
And very important: Do not use operating system environment variables. Use the KiCad path variable feature!
They are part of the git repository because they are specific to all KiCAD projects within that same repository. You are correct, they’re not specific to that KiCAD project: this is a meta-project, multiple KiCAD projects with a shared library repository.
However wrong it “feels”, it’s the only choice I’m given as we cannot know the absolute path.
In this case, the project and libraries live in the same git repository. “Moving the projects” is intended to be as simple as git checkout <repo_uri>, and doing this, the libraries’ path relative to the project path will never change.
While it is true I could set a global environment variable that defines the path where those libraries live on my workstation, that is then a set-up step that must be replicated for each and every person who needs to interact with these files.
It may be time for you to look in the more obscure capabilities of git.
Git has a lot of capabilities that you would never find without reading the manual.
One of such things is to change the “carriage return / linefeed” combination on checkout depending on which operating system you’re using.
I still believe that decoupling those libraries with an environment variable is the right way to go. Creating interdependencies between such only loosely coupled directories is just bad practice. You will have to do some kind of managment, regardless of whether you use long relative paths or an environment variable. With an variable it’s just easier to maintain.
I’m almost certain git can handle it for you, but it can also be done with a few lines in any decent scripting language. Such a script could also search through multiple projects to find inconsistencies
Yeah, I’ve already suggested looking into configuring git for line endings, since one operating system isn’t like the others where line endings is concerned. (I’d vote if favour of the contractor adopting a Linux workstation since the related firmware build environment is built on it, but that wasn’t on the table.)
A challenge unrelated to KiCAD directly is that the person running on Windows is also a git novice, whereas I’ve been using git since the days when it was merely the “backend pipes” for a front-end “porcelain” like cogito, and our manager is somewhere in-between (and has come a long way). The implementation of git being used on Windows is an Atlassian product called SourceTree, so we’ll have to research what can be done there. It should expose that setting somewhere, but then again, Atlassian do make some funny assumptions.
Installing a Python interpreter on the Windows box and just having a small Python script “fix up” those files is certainly an option, but the issue of being able to “bundle up” a pile of related projects and their libraries is hardly a unique one: so I think long-term some sort of meta-project management in KiCAD could be useful.
