kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 06/22/2018 09:19 AM, Carsten Schoenert wrote:
> Am 22.06.2018 um 14:28 schrieb Wayne Stambaugh:
>> This is not a trivial fix.  Blindly copying the default global library
>> tables every time they change would overwrite any user customization
>> which is a not an option.  It then becomes a merge operation which is
>> far more complex.  I'm not opposed to an optional merge solution if
>> someone has the time to implement it.
> 
> Yes, doing it that way is a real complex thing that will be PITA.
> 
> But why KiCad needs that file if it also could use the default
> configuration from the package and only place differential and
> additional data from the user context in that file and load the config
> from here on top of the default config?

This is a potential solution.  There is no limit to how many library
tables that can be chained.  I see several issues with this solution.

Users who track the development libraries will have most likely fully
duplicate tables in there user config which could slow down the
footprint lookup and browsing although it would be minimal.

Given our history of not getting the default install path correct,
finding the default library tables could be problematic.

Changing a symbol library table could lead to missing and/or broken
symbols which causes it's own set of issues.

Changing a footprint library table could result in unexpected footprints
being pulled into a board.

> 
> It looks a bit wrong for me to save the default data within the user
> context which will bring such difficult circumstances then.
>