kicad-developers team mailing list archive

[John Beard <john.j.beard@xxxxxxxxx>]

On Mon, Oct 29, 2018 at 2:44 PM Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>
> The PLUGIN object is very much designed for handling files on a per
> plugin basis.  The files could be on the local file system, Github, or a
> compressed archive but they are still files.

Hmm, then maybe I'm thinking on the wrong level (at the PLUGIN level).
What I really want to achieve is to make it possible to run the
parsers for all the PLUGINs from any data, not just from the file
system. The aims here include:

* Allow an interface suitable for a cut-down parse-only tool, which is
useful for debugging and instrumentation (GDB, profilers, valgrind,
fuzzers etc)
* Provide framework for command-line tools that can render out
fooptrints/boards, convert between formats, etc
* Provide framework that allows up to attach unit tests.

As you say, this doesn't actually make sense in all cases to work on
the PLUGIN interface level, as the plugin might have special magic
ways to get the data, like the Github ones, and you can't always feed
this data from a test harness.

Perhaps I should look at making the PLUGIN derivatives individually
testable in their own ways, and allow test harnesses to hook in at
*those* points? For example, the native kicad ones can take an input
stream of s-exp data, but the Github one might need a mock github-like
interface so it can optionally "pretend" to talk to github.com for
when the network side is not the code under test.

Cheers,

John