kicad-developers team mailing list archive
Mailing list archive
Re: BOM support
On Thu, 29 Jul 2010, Dick Hollenbeck wrote:
Up until seeing this BOM C++ code, I never knew a CSV file could or
would use a tab or a semicolon as a separator. I thought the C in CSV
Originally it was a comma only. With quoting rules for embedded commas.
Then it was "extended", so everyone does whatever he want.
You can have *your* perl, if this idea comes to fruition. I see you
licking your chops.
I meant only to say 'an external program' instead of 'a python script'.
Lua would be useful here, too. A scheme/lisp would read everything in
one statement if it was a sexp... and so on.
CSV is not an option for the intermediate file, since we are not dealing
with tables at this point. Each schematic part can have its own set of
fields/properties and those fields won't be unified or reconciled ( =
tabularized ) until we get over to the scripting environment. Therefore
we have to export the field/property *names* and values.
Right, I forgot this recent innovation. I wasn't supporting csv (it
sucks in a lot of ways), but only to say 'just decide on a popular
We should not rule out XML.
Never said that. I think that 90% of the useful languages can at least
read using a SAX processor (if not a DOM one). Just be cautious when
writing it, it could be tricky.
So is one + one vote enough? Or should I go back to work, and leave
this for another month or year?
It's your time. I personally don't *need* a new bom exporter, but
someone else could use it. Well, just a little feature can be useful,
some flag to avoid 'virtual' component in the BOM (fixturing,
references, shunt done as tracks and so on). But that's more a component
enhancement than a BOM one (I could simply set a "NOBOM" attribute on
the component and filter it in the postprocessor).