kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 29 July 2010 06:39, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
> I have spent most of the day in eeschema's BOM support code.
>
> One idea I have is to simplify that code significantly, because of a
> belief that we will be unable to meet all needs in C++.  It will take a
> user modifying a script for him to get truly what he wants.  Using a
> script means it requires no compiler or build environment.  For example,
> a python script.
>
> To embellish this idea:
>
> When he clicks the BOM button, we export everything we (would ever) need
> to an S-expression file, with basically NO options since everything is
> exported.  Then transparently we run an external script/executable which
> can do anything, but would be passed the name of the S-expression file,
> and perhaps a desired final output filename that might be CSV.  The
> script converts the S-expr file to CSV or whatever, maybe emails it to
> grandma.
>
> For a configuration dialog, the user only gets to name the
> script/executable that is run on the exported file, perhaps the name of
> the final file, and basically nothing else.
>
> I write 3 or 4 python scripts which duplicate what we have now in terms
> of outputs.  But the 3rd one is better, the single line per part type,
> which is the one I am most interested in, in CSV output format, with
> full field name support.  These scripts go into <bin-install-dir>/scripts/*
>
>
> I think I can load S-expressions now into python.  With this plan a
> python install becomes a nice to have, but not a true Kicad
> *requirement* since the user can provide his own executable/script in
> any language, including Java, SCALA, or C++, or not run the BOM generator.
>
>
> (BTW, I have worked with Groovy extensively and was disappointed with
> the lack of compile time type checking.  SCALA looks better in some
> ways, and has many concepts in common with Groovy.  I do not really know
> it yet.  It runs on top of the JVM like Groovy. At first glance it looks
> interesting for anyone currently working in Java.  You can actually
> write scripts in it too.)
>
>
> This is one thing that could be done to the BOM generator.  I don't like
> the current dialog window there at all, and am not too exciting about
> fixing something for which I have no enthusiasm for.  I am not sure it
> is worth salvaging.  A few lines of python code will do a better job and
> give the user the ability to easily refine the output him/her-self.
>
> What do people think?
>
> Dick

Hi Dick,

A script may not need a compiler or build environment, but it does
require an interpreter. Python is my interpreter of choice for
scripting. I like python so much it tends to pain me to write some
code in other languages when I know how easy it would be to do in
python.

If Kicad is going to rely on an external interpreter being installed
to generate a usable BOM, the interpreter choice needs to be thought
about carefully. I think I remember you saying that you wouldn't
entertain python bindings (I appreciate we're not talking about
bindings here) in Kicad until you could use python 3.x, is that right?
also, does that mean that python 3.x would be a requirement of a Kicad
install?

If the only BOM output is an S-expression (or XML, or etc.) file, and
anything else would be generated via an interpreted script I would
regard an interpreter as a requirement of Kicad, and not just a "nice
to have". As a minimum, any Kicad install should be able to produce a
human readable BOM output, which could be as simple as the standard
.lst text file without relying on an external interpreter being
installed.

The current dialog is a mess and I don't even know what works and what
doesn't, it all seems a bit random. I am sure that anything you do
will improve the situation and I'd be one happy customer with any
improvement to BOM generation.

Best Regards,

Brian.