Mail Archives: geda-user/2017/08/14/05:47:08
Hello Peter,
On Mon, 14 Aug 2017, Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com] wrote:
>Hi Igor2,
>I think I agree with you that allowing multiple attributes with the same
>name on a given object is a misfeature.
>
>I didn't have involvement in developing this code, but have a recollection
>that it came about around the time the new import code was written -
>possibly as a part of it. When importing from schematics, attributes on
>symbols get copied over to attributes on pcb footprints.
Thank you, I have the same impression looking at the project history.
>
>gnetlist allows (incorrectly imo), multiple attributes with the same name,
>and I wonder if that might be the origin of this behaviour in pcb?
Same impression on this too. That means the only data path we need to
worry about is gnetlist->pcb.
A quick grep shows pcb code looks at attribute values for 3 reasons:
1. to display them to the user (lesstif and gtk HIDs) - redundancy doesn't
matter
2. to decide settings on board or layer level - the code writes these as
unique, so the only way to get redundancy here is manual file
edit/generation in which case subsequent keys are silently ignored
3. to decide element behaviour - this is where it will start to matter for
us
I found only one example of 3.: bom.c: user specified override for
centroid/rotation ("xy-centre" and "xy-fixed-rotation"); the code uses
the first match, silently ignores the rest.
(There's also a find.c hit "PCB::skip-drc", but that's a layer attribute,
not an element attribute, so it's probably in group 2. and not imported
from the netlist; for other group 2. gets, grep for "PCB::")
So I think it would be a reasonable behaviour to switch to unique keys and
throw a warning when any input (including netlist import) has redundant
keys, as those would be silently ignored by the code otherwise.
Regards,
Igor2
- Raw text -