Use relative paths for project libraries with git-subtree

I tend to use the following libraries in my KiCad projects:

as well as a custom library that I need to use across several projects

I am okay with the first 3 being managed as Global Libraries since they don’t change frequently and are use across the board, but I thought I’d use git-subtree to manage my custom Project Specific Libraries. This would allow me to make changes within one project without necessarily breaking other schematics unless the subtree is updated.

I thought my workflow would be just to point the project libraries to a subtree but the relative path doesn’t seem to work for me in the project libraries dialogue. Any suggestions?

Project specific libs should be placed inside the project directory. Then you can use the path variable ${KIPRJMOD} inside the library tables.

my problem is that I want them up one directory. I am actually trying to design several interconnected pcb’s so there is a main “project” for which i need several compatible Kicad projects to be tracked. I’d like them all to use the same pcb library so that if for instance I correct a bug in one connector output pinout It will correct to the other.

It’s not completely clear to me what you need, but you can have a directory structure like this:

my_projects/
    common_libraries/
    project1/
    project2/

and in the project specific library table:
${KIPRJMOD}/../common_libraries/footprints

I have such a setup, but I don’t use git subtrees nor do know what they are.

This works! I wasn’t adding the ${KIPRJMOD}/ at the beginning of the relative path.

Recently I have thought that this may not be the best system. The downside is that you have always have the libraries in the same relative place and can’t therefore move the projects. It may be a better idea to define a new variable in the Configure Paths dialog and use that variable. For example

image

And
image

This way you can have even one library per project or a group of projects anywhere you want (including, of course, the top level projects folder). The downside is that if you use multiple machines you have to define the path variable for each of them.

The upside is that on each machine you only need to configure the path for “MY_LIBRARIES” for projects to be portable across all the machines. That only needs to be done once at install, not every time one opens a different shared project.

I think I understand your points, but I think for now I’m going to keep them defined locally only because I want as few steps as possible involved in someone cloning my repository from Git. My custom library isn’t that large so I’m okay for it being instantiated in more than one location for different master projects.

My directory structure could be/become:

kicad-official\
kicad-sparkfun\
kicad-digikey\
projects\
  project-1\
    custom-lib\ (version 1.0)
    sub-project-1\
    sub-project-2\
  project-2\
    custom-lib\ (version 1.1)
    sub-project-1\
    sub-project-2\

Where project-1 & project-2 are independently tracked git repositories. Each will use custom-lib as defined in a path relative to each sub-project’s .pro file.

The global paths to the top level libraries (kicad/sparkfun/digikey/etc) would have to be setup after an install but would technically only have to be done once across projects.

Changes in project-2/custom-lib (1.1) can be made to keep synchronized sub-project-1 & sub-project-2 from project-2 but won’t update project-1/custom-lib (1.0) unless I manually apply the following command from within project-1.

C:\projects\project-1>git subtree pull --prefix custom-lib custom-lib master --squash

This will update custom-lib in project-1 , potentially break it, but allow me to attempt to make and track the fixes. I can always revert them if needed. If the fixes are appropriate, I can git commit and git push these changes to the remote and (theoretically) anyone can git clone my repository without hassle. Of course they still need to have the defined global libraries configured properly but this can be documented in a README.

It uses more disk space and the developer (not user) needs to know some extra git commands but it sort of ensures compatibility of projects despite changes in an actively developed dependent library. I’m sure I’ll find a better workflow but I think this erring on the side of caution which I’m okay with. It will save time in the long run.

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