The plugin is run within pcbnew, but it will archive all the schematics symbols in to a project local project-archive.lib library, and relink all the symbols from in schematics to the ones in project-archive.lib
The plugin will also look for all 3D models within layout, copy them into shapes3D subfolder in the project folder and relink all 3D models within the layout to the local ones.
At this occasion I would like to thank to @SembazuruCDE for all the testing during development.
As always any comments and/or bug reports are always welcome.
Great. Time for me to update my copy from the master branch.
Quick note to those who haven’t installed plugins on Windows boxes. Put the plugin folders here:
%USERPROFILE%\AppData\Roaming\kicad\scripting\plugins
Note, you will probably have to create the “scripting” and “plugins” folders if you haven’t already.
Released version behaves somewhat differently to what you tested. The schematic archive option does not touch the cache anymore as there was a change in eeschema how it generates cache library.
The way eeschema behaves now, you can also archive symbols by deleting (or moving) symbol folders and running eeschema. Eeschema will then rescue all the symbols, resulting in project-rescue.lib, which will also be linked to the project. But I find this a bit awkward.
In my workflow I used to remove the “-cache” part from a library and then explicitly ad that library to EEschem and put it on top of the libraries to search.
But this will all change soon when V5.0 is released, which apparently does not use the -cache and/or -rescue libraries.
Kicad 5 will still use both of them. Both of them are not indented to be used by the end user. See them as part of the eeschema files.
(In fact having an intact cache file is essential if you want your project to survive changes to the library. And it is really important for the remapping process.)
If we are lucky kicad 6 will bring the new schematic file format which will make these two files obsolete. (As it will include the symbols inside the schematic file format similarly to what pcb_new does right now.)
It may be unintended use, but those cache libraries as they are now (V4.0.7) are a convenient hack for exchanging symbols between different projects and maintaining/creating your own custom libraries.
This isa safe way of doing things with V4. It is even possible to link the project-cache.lib without any renaming, though there is one caveat. So you need to know what you are doing.
Unfortunately V5 does not support either of these two hacks, as the project-cache.lib is encoded differently. This encoding also changed a couple of times in the last couple of months, but has been stable for a month or so, so I hope it will stay this way. This was also the reason I waited with release of the plugin.
Yes, V6 should solve all of this and make my work useless, but until then, this is my contribution to make life a little bit easier.
As a first approximation, I have little regard for the contents or format of -cache and -rescue files. I suspect most users are concerned about two capabilities:
Portability. The ability to produce a self-contained version of a project that can be transmitted to another user; and that other user can open, read, modify, edit, and save the project regardless of the other user’s library structure. A useful feature would be a built-in utility that can assist with mapping the project’s symbols and footprints into the new user’s library structure.
Archive. The ability to create a stand-alone copy of a project that can be stored in digital form for, say, 5 years (or 10, or 20), and then opened and read by a later version of KiCAD. If the project is then modified or edited it’s not necessary to save the project in the same file format as the archive; saving in the then-current file format is quite acceptable.
Both are possible if you archive or sent the cache and rescue lib with your other project files. Worst thing that can happen then is that you (or the guy you share the project with) will be asked to rescue the symbols as they do not exist in the same form in the current library structure. (Plus maybe a warning message that libs are not readable)
I do not agree it is the best possible solution but i do not really see the benefit of the bodge suggested here (or the even worse bodge of miss-using the cache lib)
