Mail Archives: geda-user/2016/07/30/13:24:51
On Fri, 29 Jul 2016, Edward Hennessy (ehennes AT sbcglobal DOT net) [via
geda-user AT delorie DOT com] wrote:
> What are your plans for the gEDA-gaf codebase? It looks like your are
> rewriting the core library in other languages. Is your plan to make
> libgeda obsolete?
I'd like to have a core library--call it libgeda, call it something
else--which is used by the gEDA programs and which can be used in other
programs and scripts, as well. This library should provide an object
model and functions for accessing it, for reading and writing files, for
rendering objects, and so on. The idea is that no application or tool
working with gEDA files should have to duplicate basic gEDA functionality.
The current libgeda doesn't live up to that. While in theory, you could
use it in another program for loading gEDA files, in practice, it's so
intertwined with gEDA and especially gschem internals that in most cases,
it's easier to just duplicate the required behavior. I'd like to move the
parts of libgeda which are interesting to use as a library out into a new
library which is used both by libgeda and the tools, merge libgeda back
into gschem, and have the new library take the place of libgeda.
My other concern is the scriptability of gEDA. While gEDA does have an
embedded Guile interpreter and makes some functionality available to it,
this approach is somewhat limited; most notably, you can't use the gEDA
API from a stand-alone script or from a script running within another
application. I'd prefer having bindings to the core library available in
a high-level language and using these both for stand-alone scripts and for
code which is run within an application. This way, the core library could
also contain commonly used functionality which is more naturally written
in a high-level language, like the netlister.
- Raw text -