Re: gEDA-user: gEDA just hit SlashDotOrg

[DJ Delorie <dj@xxxxxxxxxxx>]

If I read the thread's arguments right, I think the problem isn't
neccessarily the order of symbols, but that reading them in *any*
"order" loses some info.  For example, we don't lose track of which
refdes goes with which symbol, regardless of what order they're read
in.  But if we have to symbols with the same refdes, we only get one
footprint in the netlist - even if the two symbols have different
footprint values.  These two symbols which would normally be merged by
the netlister, would normally have their attributes merged.  If they
have the same attribute but with different values, which one wins?

One could argue that neither should "win".  The backends would call
some global function that says how to deal with conflicts for each
attribute - keep both, pick one, error if different, callback, etc.
That way, the common part need not make any assumptions about the
meaning of the data.  Some backend might want to see both footprints,
and choose based on where the schematic came from - perhaps the local
sheet can override a sheet from a library, for example, or a toplevel
sheet can override a sub-sheet in a heirarchy.

However, as Kai points out, making that change does mean a lot of work
in the back-ends to call all the "personality" functions needed to get
the data in the right semantic format.

Granted, the common part needs to make *some* assumptions about the
schematics, otherwise there would be no common code.  For example, we
assume that nets connect pins on symbols.  We make some assumptions
about heirarchy that make the circuit match its graphical
representation.  Etc.  Perhaps we just need to add a call to
"flatten_merge_schematics" or something to get the "old" behavior?  Or
perhaps some alternate data structure could be preserved for new
back-ends that need it?


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