X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Fri, 10 Feb 2017 21:29:19 +0100 (CET) From: Roland Lutz To: "John Griessen (john AT ecosensory DOT com) [via geda-user AT delorie DOT com]" Subject: Re: [geda-user] large difference in gnetlist error message between versions. In-Reply-To: <31a96361-438d-a672-8be7-5984e989d74b@ecosensory.com> Message-ID: References: <31a96361-438d-a672-8be7-5984e989d74b AT ecosensory DOT com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1008734977-1486758559=:1490" 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1008734977-1486758559=:1490 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 10 Feb 2017, John Griessen (john AT ecosensory DOT com) [via geda-user AT delorie DOT com] wrote: > gnetlist -g drc2 kvboard.sch > kvboard.sch:487x454: error: could not find refdes on component and could > not find net= attribute on pin > > It gives no clue as to which symbol has problems... As the error message says, the refdes is missing, so there is no command line-friendly way to specify which symbol it is. “kvboard.sch:487x454” means that the offending symbol was found in kvboard.sch at coordinate 487x454 (an information which I added to the error message). You probably either removed the refdes= attribute of a component by accident, or you created a power symbol (which doesn't has a refdes) and didn't set a net= attribute on its pin, so the power symbol doesn't work. > When I use Vladimir's fork: > > Could not find refdes on component and could not find any special attributes! > Possible attribute conflict for refdes: T1 > name: numslots > values: (#f 0) > Possible attribute conflict for refdes: T1 > name: numslots > values: (#f 0) > DRC errors found. See output file. The other messages are unrelated to this error. In fact, they are misleading because they state a non-error (the numslot= attribute being set on one component of a package and not on another). > cat output.net > Checking non-numbered parts... > ERROR: Reference not numbered: U? > > […] This won't help you because “U?” is just the way gnetlist used to tell you it doesn't know the refdes. It could also be that you added a component and forgot to change the default refdes from “U?”; with the old version of gnetlist, you can't tell. > So, the conversion of gnetlist to python has left out a lot of usefulness. As you can see, it hasn't. However, your mail makes me aware of one thing I haven't thought about before: gnetlist doesn't touch the output file any more if there were netlisting errors because the generated file is probably broken and shouldn't replace the old file. For DRC backends, however, it is probably desireable to overwrite the existing output even if there were errors. How do you suggest solving this? Should a backend whose name starts with “drc” always force an output file to be generated, even if there have been netlisting errors? > so I'm using https://github.com/vzh/geda-gaf/tree/unstable-1.9 The old version of gnetlist is still there in case you need it. To enable it, just add (set! use-legacy-frontend #t) to your gnetlistrc file. --8323329-1008734977-1486758559=:1490--