X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Tue, 21 Jun 2022 19:32:31 +0200 (CEST)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] Installing geda, pcb from scratch - last problem
 SOLVED
In-Reply-To: <861C6911-D8AF-4A39-BE16-D6F14801D9FF@noqsi.com>
Message-ID: <6917d6cd-6b4a-ad72-ec84-e3bd5f1d3175@grinsen-ohne-katze.de>
References: <xn35hhnpho DOT fsf AT envy DOT delorie DOT com> <400b3366-05cb-9377-8211-0a6cf0a9753d AT linetec DOT nl> <f9e44e10-34cf-657e-76b0-8314aab26441 AT grinsen-ohne-katze DOT de> <16de0564-4ae8-3d2f-d8d3-fce9cf17e4a8 AT linetec DOT nl> <92295ad-a425-4e2f-98cd-1c7a3e7dfa39 AT grinsen-ohne-katze DOT de>
 <8812571a-4edd-e6ed-7607-244efe207d5d AT linetec DOT nl> <e01d65b3-66b0-0e3e-e6ed-897368163f27 AT linetec DOT nl> <1d4b9138-f147-b299-69d5-74e3d5aadd3e AT grinsen-ohne-katze DOT de> <5eeadbd6-a72d-ecb0-5767-62657edc4a5e AT linetec DOT nl> <7e259699-61ea-8050-18d1-5109797c6cc8 AT linetec DOT nl>
 <20220621160643 DOT 49d35762 AT jrenewsid DOT jretrading DOT com> <152271d6-1656-1988-e6ca-85ec62fe78b1 AT grinsen-ohne-katze DOT de> <861C6911-D8AF-4A39-BE16-D6F14801D9FF AT noqsi DOT com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1212817031-1655832751=:7651"
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-1212817031-1655832751=:7651
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Tue, 21 Jun 2022, John Doty wrote:
> Why do you say that? I’ve had no difficulty, and I have many legacy designs.

gEDA has a quite complex logic for translating schematics and symbols into 
a netlist.  Unfortunately, much of this is neither documented nor tested, 
but legacy designs do depend on this behavior.  (At least the designs from 
our university which I looked at did, even to the point of exposing so-far 
unknown bugs in gnetlist.)

If, as a maintainer, you want to make sure netlists for existing designs 
are generated correctly, you have basically two choices: either to not 
touch the netlisting code at all, or to be VERY careful about 
understanding what the existing code does, making sure your changes pass 
the existing tests, and adding new tests as appropriate.

I chose the second approach.  Untangling the internals of gnetlist took a 
lot of time and effort to do, and I ended up introducing some 
well-documented changes to the netlist output[0], but I was able to 
increase the readability of the netlisting code to a point where it is 
able to serve as a kind of documentation-substitute[1] and added 
regression tests for those instances where I missed a corner case which 
existing designs turned out to rely on[2].

There has been no such effort in lepton-netlist.  The reference output for 
existing tests was simply replaced with the output the newly written code 
gave, declaring this as the new correct output.  I'll happily believe this 
works as long as the schematics and symbols don't make use of the more 
obscure behaviors of gnetlist, and it could even be argued these were 
design flaws in the first place, but that doesn't change the fact that 
there are many designs out there for which this approach simply can't 
work.

Roland


[0] http://git.geda-project.org/geda-gaf/tree/xorn/tests/netlist/README
[1] http://git.geda-project.org/geda-gaf/tree/xorn/src/gaf/netlist
[2] http://git.geda-project.org/geda-gaf/tree/xorn/tests/netlist/regression

--8323329-1212817031-1655832751=:7651--