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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
