New library file format

Hi all,

Just out of curiosity. When the new library file format came out, will it be possible to use the old symbol libraries?

Of course. You will probably be able to read old libraries forever (at least for quite a while), but the ability to save libraries in the old format will likely get removed.

Will the new library format eliminate or minimize stupid merge-conflicts on github/gitlab where git doesn’t understand what parts of the file-edit are really new and what parts are old?

It will be like the footprint format is now, each symbol will go to its own file, so it will certainly reduce conflicts.

Not necessarily. The inheritance stuff might get tricky if every asset is in a separate file. So it could be that multiple assets are in one file reflecting the inheritance structure or it could even be that all symbols are in one file.


I also have to disagree with the general premise that the current file format makes this impossible. Merging is easily possible as long as you ensure everyone is on the same kicad version (major version! Different kicad versions can have different line orders.) and as long as you work with git as intended. Meaning one commit per atomic change. For example: one commit for “fixed pin placement of asset x” a separate commit for “add asset y” as well as one completely separate commit for the first save after file version update (for example if the version update changed the line ordering).


I am of the opinion that the inheritance feature is more important than (unnecessarily) simplifying library merges. (Why reduce kicads feature set to fix some other problem that can be avoided by properly handling git or any other version control tool)

Per symbol files will be very slow loading on mechanical hard drives. There are far more symbols than footprints.
I still think a sqlite database would be a better solution, but maybe V7 now as V6 is already well underway

3 posts were split to a new topic: Slow footprint library loading

Have discussed that question 2 weeks ago with Wayne and here is what he wrote about:

Mandatory header for each file. The library file layout has not yet
been finalized. I am currently considering a hybrid approach where you
can have either one file with many symbols per file as well as single
symbol per file both in a folder similar to the current footprint file
format.

1 Like

Not unless the devs take care to make the implementation “git friendly”, which historically they haven’t been too concerned about.

However, git works best with code, where the order of lines is generally important. Certainly, when you do “save” not even Eclipse saves the lines in a new (random) order, which is often what happens with a data format.

Working on this. See the KiCon panel for some detailed discussion.

Harsh. :slight_smile: Periodically, we accidentally rearrange the order. These are bad commits and we generally revert or fix them when we notice.

1 Like

Sorry :slight_smile:

I was doing a lot of rework on the TTL lib, I found pins would change order for no reason I could work out. Logically I might expect it to be pin number, I’m not sure if it is easy to define an order for all types of item.

1 Like

Git doesn’t give any preference to text in storing. Everything is a blob. But the tools it invokes tend to be text oriented of course.

I suspect that initially pin order in the file might start off in the order that you add them.
After that they might get shuffled to pin number sequence or by position on the sheet or by type. Lots of possibilities.

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