Re: gEDA-dev: SoC Hopeful

[Dan McMahill <dan-at-NOSPAMmcmahill_dot_net>]

Peter Clifton wrote:
> On Mon, 2007-03-19 at 08:24 +0530, C P Tarun wrote:
> [snip]
> 
> 
>>I suggest that from Day 1 itself, we decide to build not just these features
>>into gschem or elsewhere, but also build a Perl-callable library to access
>>this database, read from it, write to it, etc. With such a library
>>being included
>>in the core source base of geda, future tool writing will become hugely simpler.
> 
> 
> "C" Libraries are perl-callable aren't they? I Presume there must be a
> way to write a language binding for a "C" API.
> 

I haven't tried it, but swig looks pretty cool.  It is a framework for 
easily providing perl, scheme (guile), and several other language 
bindings to a set of C functions.

>>I've wished hundreds of times for a proper, "official" Perl-callable library
>>to parse a layout file, a footprint file, or a schematic file, and load the data
>>into an in-memory data structure. Such a library to read and write these file
>>formats would dramatically reduce the activation energy hump to write
>>a rich set of tools for all of us.
>>
>>For such a library to be useful, it would have to be maintained with the
>>same degree of seriousness as the C/C++ source of gschem and pcb.
>>The library should not be allowed to fall out of sync with the changing
>>file formats that the primary programs handle. And if it's too difficult to
>>keep two different parsers in sync, then the C code for the parser used
>>in the original programs should be encased in wrappers and then made
>>available as Perl-callable functions. (Perl can call suitably encased
>>C code.) That way, the two parsers will never fall out of sync.
> 
> 
> It would not fall out of sync with the changing file-formats, because
> you wouldn't write yet another implementation of the parser,
> data-structures etc, nor would you copy-paste code.
> 
> You would have one library which is used by all tools (probably in C as
> this is what the suite mostly uses), then you would provide language
> bindings so people can write the useful utilities they want.
> 
> If this means having to split code out of existing tools and into a
> library, that is the way forward in terms of code reuse.

I completely agree.

-Dan


_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev