X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Mon, 14 Aug 2017 11:47:25 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] [pcb] mainline: redundant attributes: bug or
 feature?
In-Reply-To: <CAJXU7q9BuoyrMLQ04sZ98NVc0rMjjUaUZ1Zb+pqn=pA3meePag@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1708141129590.27212@igor2priv>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1708140646240 DOT 27212 AT igor2priv> <CAJXU7q9BuoyrMLQ04sZ98NVc0rMjjUaUZ1Zb+pqn=pA3meePag AT mail DOT gmail DOT com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

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