kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #32815
Re: Some thoughts on symbol remapping
Hi Wayne,
I just tried the remapping tool as well, and wanted to share some
thoughts on it. This e-mail, where you're explaining how the remapping
process works seemed like an appropriate place to reply.
I tested this two weeks ago, using the 2017-12-22 daily build ppa, but
didn't get around to writing up my experiences until now.
Remapping of most of the symbols in my project failed. I couldn't quite
reproduce what was failing (and in my reproduction attempts, I think I
overwrote the .pro file backup, so can't start from scratch), but I
think the problem was that I used to have /usr/share/kicad/library as a
symlink, but added the libraries using their canonical path to the
library table. I realize that there was a recent fix for this, but I had
that fix included (looking at the build date). I suspect that fix only
works when the actual file is a symlink, not when a directory further up
the hierarchy is a symlink, but I didn't actually test this.
> The remapping will not look up by symbol name in the symbol library
> table if the symbol is not found in the original library in the old
> library list that it was loaded from.
I was quite surprised that this didn't happen. In particular, the
remapping tool said it couldn't find some symbols, while they were
certainly available in the list of libraries I configured. I did not
understand why it would not find them.
The procedure implemented now (find the symbol in the old list first)
totally makes sense. However, I would think that *if* this procedure
fails, looking up the symbol by name in the new list could be a good
fallback?
As I said before, I can't quite figure out what the problem was for me,
but I can imagine various ways where library layouts, or library
locations change. Especially considering that a project is only remapped
when it is opened, it might be that we'll be remapping projects years
after the upgrade to v5, or maybe we'll be remaping projects published
by others, in both cases it seems likely that libraries live in
different places. Would it not make sense to do a best-effort matching
in this case, instead of just not remapping the symbols?
Some extra confusion rose from the fact that, even though the symbols
failed to remap, they were still shown properly. Only when opening the
schematic a second time after remapping, the symbols were shown as
question marks. I suspect that directly after remapping, eeschema still
had the original libraries loaded, which were removed from the project
file the second time. Would it make sense to actually unload the old
libraries after remapping (if this is indeed what happens)?
> Look for the library by path and full file name in the global symbol
> library table. If the library cannot be found in the global symbol
> library table and the file exists, add this library to the project
> symbol library table and give it a unique name if necessary.
Is this last part implemented already? I couldn't find any reference in
the code when I looked, and I *think* my setup should have triggered
adding new libraries instead of failing to remap.
Gr.
Matthijs
Attachment:
signature.asc
Description: PGP signature
Follow ups