kicad-developers team mailing list archive
Mailing list archive
Re: BOM support
On 07/29/2010 08:22 AM, Brian Sidebotham wrote:
> 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
>> 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?
> 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
Are you interested in writing the 3 scripts? I would gladly defer to
your python prowess on this for initial coding. We can then keep the
door open to refinement thereafter, no?
I can send you a hand made XML file while I go to work on the export to
actually be able to create such a file. We can work in parallel.
Are you game?