kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Hi Brian,

On 3/11/2019 9:58 AM, Brian wrote:
> Hello everyone,
> 
> tl;dr - hi, I'm new here and I'd like to suggest a couple small changes
> to make maintaining my private fork a little easier. Presuming I can
> present a concise patch that adheres to the coding standard, what's the
> right way to propose it?

The correct way to propose a patch for KiCad is to commit to your local
branch and use `git format-patch` and send the patch to this mailing
list for review along with a description of your changes.  Depending on
everyone's schedule, it may take a bit to review the patch submission so
patience is a virtue.

> 
> ===Background===
> I've been maintaining my own private fork of KiCad for a few years now,
> but only just now joined the developer list because I've just had to do
> a major rework on my fork due to large upstream changes (the reason this
> has only just now occurred is its own long story) in the area of
> EESCHEMA symbol library structure.

Don't get too comfortable, there are a lot more changes coming to the
symbol library code structure.  The symbol library table and the plugin
architecture were merely the first steps. There will be a new library
symbol file format along with some low level object code changes to
support the new file format.  I typically post to the mailing list when
I make large architectural changes so you should keep an eye open for
announcements so you are not blind sided by these changes.

> 
> My fork exists to add the ability to use an RDBMS (e.g. MySQL) via ODBC
> as the backing store for symbol and footprint libraries.  I've done this
> because I maintain a parts inventory database in MySQL and having
> symbols / footprints tied to parts I actually have is a useful
> correlation.  Inside the database, symbols are serialized in the legacy
> EESCHEMA format.

The legacy symbol library parser will always be available in order to
read older symbol libraries.  However, once the new symbol library file
format is stable, the legacy symbol library output formatter will be
removed from the code base and all new symbol libraries will have to be
created using the new file format in order to support the new features
planned for symbols.  The new file format will be s-expression like the
footprint library and board file formats.

> 
> At any rate, as one might guess, it's been a distinctly nontrivial
> endeavor, since the latest upstream code has rearranged the way symbol
> libraries are organized.  That's okay, I slogged through it and put it
> into the right shape to work in the new paradigm.  But along the way...
> 
> ===Suggested Upstream Changes===
> 1. The current upstream code that "speaks" the old EESCHEMA symbol
> format is buried inside SCH_LEGACY_PLUGIN_CACHE.  In my fork, I have
> extracted it to its own class so that my plugin can make use of it, and
> that extraction uses base LINE_READER and OUTPUTFORMATTER in its
> interface so the caller has the freedom to use something other than a file.

I'm fine with this change.  I would have done it that way myself if I
had known that the cache interface needed to be exposed.

> 2. There are a few places in upstream code where a plugin type of
> SCH_LEGACY is assumed, rather than asking SCH_IO_MGR what it actually
> should be (presumably because in upstream, there is only one plugin
> type).  I changed those to use SCH_IO_MGR's methods to actually get the
> correct plugin type.

I'm fine with this change.  Since there is currently only one plugin,
there was no need to use SCH_IO_MGR's methods to get the correct plugin
type.  This was going to get changed anyway once I implement the new
file formats but if you get to it before me, that's less work for me.

> 
> On a slightly longer view, it might be nice if SCH_IO_MGR maintained a
> static registry of file extensions and plugins that other pieces (e.g.
> the library file browser) can use; for now, I use a different header
> inside a file named <something>.lib so that I don't need to touch the
> file browser filters.

I planned on adding code for this once I write the new file formats.
Once again, if you get to it before me, feel free to submit a patch.

> 
> My code isn't ready for prime-time, in no small part because it is
> unique to my particular database strategy and probably isn't useful to
> anyone else.  But it would be a significant advantage for my future
> maintenance efforts if these two changes made it into upstream.

Database support has been requested by many users over the years so I
think your being a bit pessimistic about the usefulness of a database
plugin.  If you could make it more strategy generic, it would certainly
be useful to a fairly wide audience.  You may want to consider keeping
your code up to date against the KiCad development branch so that you
can propose merging it at some point in the future when you are ready.

Cheers,

Wayne

> 
> This e-mail was wordy.  Thanks for reading it.
> Cheers,
> -Brian Henning
> https://github.com/lotharyx
> 
> _______________________________________________
> 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