kicad-developers team mailing list archive

[Mark Roszko <mark.roszko@xxxxxxxxx>]

>Why doing triple work?
It's not?

>- C++ isn't exactly the best language for a reporting feature;
Primarily when I say C++ right now, its the already existing options
and not adding new ones.
Could they be converted later? Maybe but the pcbnew/kicad format still need.

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

That wasn't the plan. That would be insane. It would still use
xsltproc if I keep the xslt option with maybe libxslt is going direct
but none of it would include xml processing directly in kicad.

>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.

The whole point of my changes is to have the options. I don't want a
billion bom scripts to generate all the different variations of a csv
format. I want one with options. I don't want to be fussing with file
paths, I just want to click, click, done and give me a nice error
message if anything went horribly wrong. Then if users could also
share their scripts and all others had to do is drop it into a
KICAD_BOM_PATH location to use and KiCad automatically picks it up and
displays it as an option? Even better.