kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

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

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

--
Lorenzo Marcantonio
Logos Srl