Re: gEDA-user: multi-part symbol support

["John P. Doty" <jpd@xxxxxxxxx>]

Kai-Martin Knaak wrote:
> It took me quite a while to flex my hacking muscles. Anyway, finally my 
> little hacking project reached a stage that actually represents an 
> improvement: 
>
> When dealing with footprints my local version of gnetlist does not care 
> for the order of symbols anymore. If there is a set of symbols with the 
> same refdes, only one needs to bear a footprint attribute. It doesn't 
> matter which one. The generic case is symbols with power pins split to a 
> separate power symbol.  
>   

This is indeed an improvement. Your logic is good. But it's only a 
partial fix. There are many attributes that need similar treatment. 
Anything that goes into a BOM, for example. That's an open ended list, 
since I think many of us use custom attributes for our flows. A one-shot 
solution for each attribute won't work. Nor, I think, is it right to do 
this for all attributes, as "source" is potentially properly multiple, 
and we shouldn't preclude other such attributes. Now, "source" is 
handled by the front end, so at the moment it's outside this discussion, 
but I consider that to be a bug, too: it precludes making hierarchical 
back ends.

I think it would be better to have a function 
gnetlist:get-all-attributes that returns a list of lists of (name, 
value) pairs, e. g.

(
    (
       ("refdes" "R1")
       ("footprint" "0603")
       ("value" "680")
    )
    (
       ("refdes" "C1")
       ("footprint" "0805")
       ("value" "470 pF")
    )
)

Then, change gnetlist:get-package-attribute to a scheme procedure in 
gnetlist.scm, with your logic implemented there for all attributes. That 
shouldn't break any existing back ends, since 
gnetlist:get-package-attribute only returns a single attribute value 
anyway, but it puts the control in the back end, where it's flexible and 
configurable. Where it belongs.

If you want to collaborate on this, I'll volunteer to do the easy part 
;-). That, of course, is the handful of lines of Scheme that need to be 
added to gnetlist.scm (filtering data structures is easy). You've 
already done the really hard part, which is penetrating the logical 
structure of the front end: all you'd need to do is compose 
gnetlist:get-all-attributes.

> In addition, gnetlist detects if there are different footprints attached 
> to a single refdes and warns accordingly. 
>
> Unlike what I had in mind last week, this this not achieved by merging 
> symbols in the internal representation. Instead, gnetlist copies the 
> footprint attribute to all symbols with the same refdes. So no data is 
> lost during this additional preprocessing stage. 
>
> I'd like to see this bug fixed in the main distribution of geda, too. 
> How would I go ahead? Should I send the patch files to this list for a 
> review? Or should I attach them to a bug report?
>
> ---<(kaimartin)>---
>   


-- 
John Doty      Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx 



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user