gEDA-dev: Pinning down libgeda

[Dan McMahill]

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