gEDA-dev: Pinning down libgeda

[Dan McMahill]

Steve Meier wrote:
> 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.


What datadraw does is it lets you describe your database in relatively 
simple terms and then it compiles this description into c code that 
implements all of the underlying database code including all the 
{de,}constructors, and accessors.  The bad part is if you want to do a 
full recompile from the true source you need to have datadraw installed 
to convert the datadraw input file into the c code.  Also the generated 
code can be pretty big.  Note that the generated code should not be 
interpreted as code which should then be parsed or edited by a person, 
it is compiler output where the output happens to be in c.  The good 
news is that if you distribute the generated c code along with the 
datadraw input files, then the end user doesn't actually need datadraw. 
    The penalty is just the size of the distfile.

It really seems that the right approach is to build on gnetman 
(actually, by this I mean the database schema defined for gnetman) as 
the internal database.  It was designed by someone who has lots of 
experience and it is powerful enough and scales well enough to support 
very large (chip-scale not just board scale) designs.   Then you could 
have scheme backends which use scheme calls that are just wrappers 
around the datadraw functions.

I guess what I'd hate to see is a lot of work put into improving 
gnetlist (which needs improving) only to find that the underlying 
database structure and methods for accessing it still aren't complete 
enough, fast enough, or scalable enough.

All that said, I'm very happy to see someone working on gnetlist!

-Dan

>. 
> 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
>>geda-dev at moria.seul.org
>>http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
>>
> 
> 
> 
> 
> _______________________________________________
> geda-dev mailing list
> geda-dev at moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
>