gnetlist fails to use inherited refdes= attribute

[Peter Clifton]

Whilst this is a rare thing to want to do (most symbols have (if any), a refdes such as "U?" or "C?", I encountered a design at work which failed to netlist with git HEAD gEDA.

I discovered the refdes had been attached inside the embedded copy of a symbol, rather than attached as a schematic level attribute of that symbol.

Since it is conceivable that someone might want a symbol with a refdes defaulted inside it, we should probably support such usage.

[Peter Clifton (pcjc2)]

I've attached a test-case.

Netlist with "gnetlist -g PCB embedded_test_case.sch"

Gives the error message:

"Could not find refdes on component and could not find any special attributes!"

Refdes should be C100, as in the embedded symbol data.

[Peter TB Brett (peter-b)]

I attach a patch which fixes this bug. However, I'm not sure whether to commit it. The main problem is that failing to attach a refdes attribute is a common error, and with this patch all components to which you've failed to attach a refdes will silently just use the generic inherited refdes attribute (e.g. "refdes=U?").

At the same time, I'm loathe to add "special case" handling. This seems more like the sort of thing that DRC/schematic consistency checks should be used to detect. WDYT?

[Peter Clifton (pcjc2)]

Longer term, perhaps we should consider adding a mechanism to provide place-holder attibutes in symbols which are not actually evaluated when computing the "effective" value of a particular attribute for a given entity.

This would allow the distinction between a default attribute in the symbol which is inherited and useful, vs. a hint or suggestion that the user _should_ add a particular attribute in the schematic.

[Peter TB Brett (peter-b)]

Yes, such a mechanism would be handy. I think I've more-or-less decided that we shouldn't commit this patch right now. If someone finds the bug annoying they can apply it locally, I suppose.