X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f Date: Thu, 9 Jul 2015 19:32:30 -0400 Message-Id: <201507092332.t69NWUEN006109@envy.delorie.com> From: DJ Delorie To: geda-user AT delorie DOT com In-reply-to: <559EFE69.1040601@zoot.drehmel.com> (message from Robert Drehmel on Fri, 10 Jul 2015 01:06:17 +0200) Subject: Re: [geda-user] Back annotation References: <559E86A4 DOT 3040109 AT ecosensory DOT com> <201507091843 DOT t69IhGF6028321 AT envy DOT delorie DOT com> <6392CE1A-AFA0-4D62-979C-3F35786422BD AT noqsi DOT com> <201507092127 DOT t69LRHRC001744 AT envy DOT delorie DOT com> <559EFE69 DOT 1040601 AT zoot DOT drehmel DOT com> 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 > How do you think this mapping tool should get the data from the schematic - > via a special scheme netlist script or by reading the schematic file itself? Nothing should read the schematic itself. I thought of two ways: 1. The various tools that deal with attributes also know about "implied" attributes, which are the result of database and ruleset queries. Thus, in gschem's attribute window you'd have access to the database as well as user-specified attributes. This lets the user override the rules while still having the convenience of a database. 2. The netlister would need to feed its data into some sort of engine that combines the specific attributes with implied ones, adds in other external data and/or back-annotation data, and produce whatever the backend needs.