kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 07/29/2010 01:25 AM, Lorenzo Marcantonio wrote:
> On Thu, 29 Jul 2010, Dick Hollenbeck wrote:
>
>   
>> 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?
>>     
> That most people on Windows (and some on Un*x too) don't have python
> installed (I had to install it to use bzr). Other than that is a good
> idea.
>
> Maybe just keep in a 'simple' report for the non-scripting-abled people
> (like the current 'sorted by reference, all fields') one)
>   

It's actually pretty much garbage.  I really would like to see it go
away before it gets expanded on by the next guy who is unhappy with the
output.  Everyone has their own needs here.  Nothing precludes the
sharing of scripts with others on the mailing list.  Or if you want to
write a custom one and keep it for yourself, that is OK, or if you want
to use only the supplied scripts, this is ok too.  We can ship 18 sample
scripts, and the user can pick which one gets chain executed.

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
meant comma.  This is one of those areas where a needs analysis
discussion might have been helpful before writing all this code.  I am
trying to do that now.


> And, since it's external anyway, just say 'an external postprocessor' (I
> would do it in perl, for example :P). 

You can have *your* perl, if this idea comes to fruition.  I see you
licking your chops.

> I think that the intermediate file
> would be something like the 'module report' in pcbnew, it can be a sexp,
> an xml file, yaml or even a csv file, I have no preference on this
> (well, I actually loathe xml :D). 

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.


I woke up this morning leaning towards a comprehensive XML export as the
intermediate format, because just this week I used xsltproc to transform
an XML file to another format with ease.  Xsltproc is easy to use, and
provides another option for us if we use XML as the intermediate file
format:


    $ xsltproc stylesheet.xml  schematic-parts-intermediate.xml  > bom.csv


xsltproc is just another option, I think python is best for the 3
samples though. 

We should not rule out XML.

> Taking to the extreme a BOM reporter
> could actually traverse without much problems the whole .sch hierarchy
> :P:P:P
>
> OTOH the *current* bom lister is becoming... unwieldy; I'd like a trim
> to it, too. With your proposal would be more or less a scan like that
> done by the search function, just dumping away the object attribute.
>
> I vote for it.
>   

So is one + one vote enough?  Or should I go back to work, and leave
this for another month or year?


Dick