kicad-developers team mailing list archive

[Mark Roszko <mark.roszko@xxxxxxxxx>]

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.


Then each engine would decide how to execute the specified script or
C++ library.The engines only take care of the intermediate steps to
actually invoke the proper script or netlisting engine. In fact all
three could have XML definition files (optional) for the options UI.
So once you press BOM/netlist it will pass the options as args to
python or xslt or the library. At which point its up to the target.
Then additional engines like using Ruby or Perl should be very easy to
implement as it'll purely pass args in whatever needed format and tell
it to execute.



The main thing I want to get out of this is options. Sometimes I want
to BOM X,Y,Z properties, sometimes I want all components of same value
or footprint grouped or sometimes I want every component on a new
line, etc.


This would eliminate having 3 different scripts for CSV generation in
python like you have now and you would only need 1.


We could also drop xslt and go for supporting python + C++ + other
future languages that aren't xslt.

On Wed, Nov 4, 2015 at 12:12 PM, jp charras <jp.charras@xxxxxxxxxx> wrote:
> Le 04/11/2015 17:43, jp charras a écrit :
>> Le 04/11/2015 17:15, Mark Roszko a écrit :
>>> I eagerly await a plugin framework. I want play around with overhauling the
>>> netlisting/bom into plugins rather than XSLT and the C++ combo right now.
>>> I originally wanted to create a way more advanced XSLT system complete
>>> with configurable
>>> displayed user options parsed from a definition XML but writing C++
>>> plugins makes it so much easier and allows more complex logic...sanely
>>> instead of accidentally summong Cthulhu trying to do the same in XSLT
>>> :D
>>>
>>
>> For BOM generation, please also consider python scripts, like the
>> footprint generators/footprint wizard.
>>
>> XSLT was used when the BOM generation from our generic netlist replaced
>> the internal generator, but now (and since a long time) BOM from python
>> scripts are (from my point of view) more easy to use, and more powerful.
>>
>> I am now using only python scripts for BOM generation.
>>
>
> I forgot:
> see <kicad src>/scripts/bom-in-python
>
>
> --
> Jean-Pierre CHARRAS
>
> _______________________________________________
> 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



-- 
Mark