← Back to team overview

kicad-developers team mailing list archive

Re: future developments: shared libraries and dynamic plugins

 

On Wed, Nov 04, 2015 at 12:15:36PM -0500, Mark Roszko wrote:
> It certainly wouldn't be closed off. It would simply be  setup with
> "generator" engines.
> -xslt
> -python
> -C++ library
> Each would implement a "generator engine" abstract class so they can be swapped.

Why doing triple work?

- C++ isn't exactly the best language for a reporting feature; lisp,
  perl, python are way better suited and there is *no* performance
  concern on this; XSLT is an evil spawn but can do the trick someway
  too (I just don't want to know :D). If we were in the '60 or on OS/400
  I'd say the right language would be RPG :P

- lisp, perl, python have no issues reading the XML netlist/BOM
  precursor; AFAIK there is wide support for XML in all the major
  languages;

- If you really want link in libxml2 or something and write your
  processor in assembly/C/C++ whatever

- => just keep the current XML exporter and not mess with subclasses,
  plugins, engines or whatever. It just works

Some kind of option interface *could* be useful, but usually once you've
tuned your format you don't need to change it, so just a command line
for the BOM processor program could suffice.

-- 
Lorenzo Marcantonio
CZ Srl - Parma


Follow ups

References