On Sunday 15 April 2012, Felix Salfelder wrote: > I was wondering about why anyone would want to use gnetlist, > when gnucap can read the geda/gschem netlists.
I think the real answer to this one is to support non-gnucap users of geda. Ultimately, a new program based on the gnucap library could support that need, but it does not exist yet. This new program would be a command line program that simply reads using one language plugin, and writes using another, thereby providing translation. >From a geda/gschem perspective, the goal is to provide an in/out path for geda/gschem. Other paths are nice, but not primary goals. >From a gnucap perspective, the goal is to provide an in/out path for gnucap. Other paths are nice, but not primary goals. Is it geda/gschem's responsibility to provide a path from kicad to gnucap? Obviously, no, but that doesn't mean it can't. Is it gnucap's responsibility to provide a path from geda/gschem to ngspice? Obviously, no, but that doesn't mean it can't. There is some redundancy here ... the responsibility for the path between geda/gschem and gnucap is shared. Either or both could provide it. The responsibility for the path between Kicad and gnucap is shared. Either or both could provide it. If gnucap provides the geda/gschem to gnucap path, and the kicad to gnucap path, a geda/gschem to/from kicad path will also come out of the work. Such a path is nice, but not a primary goal of gnucap. Let's say it could be a secondary goal. The promise of a geda plugin for gnucap is not a reason to stop work on the gnetlist verilog export plugin. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
