Re: gEDA-dev: SoC Hopeful

["C P Tarun" <tcpip@xxxxxxxxxxxxxxxx>]

> In addition to Dan's comments, I'd like to add some ideas of my own,
> mostly details but they may be useful to think about during the design
> phase.

Brilliant, I thought.

I had one suggestion, but I don't know whether this is the right place to
talk about it. It's related to the implementation of the ideas you and
others have been discussing.

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.

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.

If this is not the right time to discuss implementation issues, please
ignore my post. :)

Tarun


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