initially when I started creating kicad project I create one git repository and has subfolders per project.
Each project had a standard structure of Design, Documentation, Mechanical
Within Design I have “Fabrication” “Library” and then kicad files
I would typically have a per-project local library storing local parts but I have been building up project agnostic libraries (CRCW0402, CRCW0603, Microsemi_Igloo2, PowerTerminals, SiTime_Osc).
Two complications have arisen from this. This “central” library was part of the main KiCAD_Projects repository
I switching between linux and windows with regards to point to a central library area outside of the project area (essentially up two directories)
growing need to track changes on a per-project basis
I have created the needed repositories for the main projects but now the central library needs to be dealt with, especially considering windows and the path. I am tempted in utilising submodules and instantiate the central library into each projects’ library directory to manage this.
Are there any recomendations with regards to structure, central and local libraries and dealing with different file structures
Generally i think a central approach is more scalable and very well suited for long term work while project local libs make it very easy to share your work with others who do not care about creating a long term support infrastructure.
You sound more sophisticated that I when it comes to library structure(s). When I first started Kicad I didn’t like the libraries stuck down in the Kicad program folders (Win10). I put them in a library C:\KicadLib…
All my Kicad projects are under:
…\Documents\CAD\Kicad\ all in project folders.
If I reinstall Kicad say from 5.1.5 to 5.1.6 I don’t install the libraries in the distro I just keep what I had.
Personally I stay away from Github unless I need something. I don’t like the idea of something changing en-mass.
The thing with the variables, something has to change each time you jump between platforms, unless it is relative to the project.
This is why I think a submodule with the library would work and this has the benefit that you check out the version of the central key to that project. This has the benefit if you have a problem with a library part and then later fix it but still want/need reference to the old.
As it GitHub, this is a private git server on one of my home servers all managed with gitolite
I do not follow. The variables are set per platform (or more precisely per setup) and the assets use these variables such that they work on every platform. This is after all how the official lib works.
Submodules fall under the project specific setup that has benefits but also drawbacks (main drawback is that it scales quite badly with the number of projects one has to maintain)
Ahh then I misunderstood such variables (I did intially try those but ran into problems)
While I agree submodules are akin to project specific setup, it does have the advantage of you wanted to freeze a design with an older symbol while permitting the central library to carry on being developed.
I recently did a design and completely screwed up the RAM footprint (footprint correct, just wrong one for the ram…). I would want to update the library to fox this issue if I wanted to use this ram again, but I would want rev1 to still have the old library
i was always nervous of the cache (esp with upgrades) for such purposes so it is good that v6 will be more like a self-contained archive.
ill start the process of making a git repository for my central library and have a clone residing at the same level as all my projects. The onus of this came about because i have an IMS card out for quote and the assembler was unable to get a response from ERNI and while would prefer ERNI for the M8 SMD terminal, i can accept an alternative and thus my “power terminals” and equally version of a project are expanding
