kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

Den 6. jan. 2018 1.08 AM skrev "Wayne Stambaugh" <stambaughw@xxxxxxxxx>:

Hi Matthijs,

On 01/03/2018 02:40 AM, Matthijs Kooijman wrote:
> 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 symlink issue has been fixed so duplicate libraries will not show up
in the project symbol library table with different nicknames.

>
>> 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?

Doing this would completely defeat the purpose of the symbol library
table and reintroduce the bug that has existed since the beginning of
the project.  Symbols are now required to be mapped to a specific
library.  No more searching through the list of libraries and hoping
that the first instance of a symbol is the correct one.  If the
remapping algorithm cannot find the exact library match which is
currently being used (and should be in the project library list or the
cache) to provide the symbol, then there is no way to determine the
correct library and therefore cannot be remapped.  It also means that
your schematic is already broken.  This is why you should not skip the
rescue feature.

>
> 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?

This should not matter.  As long as the cache library is correct, then
the rescuer can create a rescue library which will contain the correct
symbols.  If you cache library is invalid, then you schematic is already
broken because the rescuer cannot rescue symbols that do not exist in
the cache library.  The remapper should have no issues when the rescue
is performed correctly.  I will repeat, do *not* cancel the rescue or
you are likely going to have issues.  I am going to add a dry run
feature but it's not going to be as dry as I would like it to be.  In
order to do this, the rescue library must be generated which changes the
existing rescue library if it exists and changes the project library
list if it doesn't.  That means at a minimum I will have to back up
those files and restore them at the end of a dry run which is risky but
I cannot think of a better way to handle this.


Is it not possible to just keep this new rescue library in memory instead
of storing it on disk?


>
>
> 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)?

This is the cache at work which works until the schematic is saved.
Once the cache is rebuilt using the symbol library table, any symbols
that did not get remapped will have broken links.  I'm not sure what the
best solution is here so I may have to rethink this particular behavior.
 Regenerating the cache library before saving the schematic is risky and
somewhat atypical but that may be a solution to this issue.

>
>> 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.

Yes, it exists in eeschema/dialogs/dialog_symbol_remap.cpp.

>
> Gr.
>
> Matthijs
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp