kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #21149
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