Dan, 1) compatability with most of the current back ends is one of the goals.
2) gnetman looks interesting and if I understand it it drags in datadraw with it. I would propose looking at integrating gnetman as schem function calls and what ever gnetman does with datadraw is ok by me. At least for the time being. Thanks, Steve M. Dan McMahill wrote: > Steve Meier wrote: >> I have been keeping silent about this. But I am in the process of a >> major rewrite of the netlist program. In this process, I folded libgeda >> into my code base with the intent of eventually extracting it again in >> some form or another. >> >> My work has >> >> 1) rewritten the struct.h data structures. >> >> 2) rewritten large amounts of the code for supporting these data >> structures. Including attempts to keep the api consistent from object >> structure to object structure. >> >> 3) rewritten the netlist algorythms >> >> 4) made heavy use of GList and GString data structures from gtk >> >> This new netlister, currently supports hierarchical buses. It is capable >> of exporting net lists for pcb and almost for PADS-PCB from mentor >> graphics. It also supports a BOM generator. >> >> There are numerous bugs that still must be fixed (embeded symbols arn't >> supported and must be). But I would request that those interested in a >> clean up of the data structures and API to please take a look. >> >> Thanks, >> >> Steve Meier > > I have several questions. > > It sounds like this is incompatible with gnetlist and the 20 some odd > backends we have? > > Any consideration to taking advantage of gnetman and datadraw now that > datadraw is much more accessable? > > I think these first two are fairly important. The first because we > have a lot of functionality there and the second because Bill Cox has > had quite a bit of experience in dealing with code that processes > large hierarchical netlists and it seems like something well worth > taking advantage of. > > Is there still an interpreted backend to make it easy for end users to > come up with their own netlisters? > > I'd see this actually as an opportunity to build the internal database > in a good way and then provide a more sane and complete scheme api for > accessing the database. > > -Dan > > > > _______________________________________________ > geda-dev mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev > _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
