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
