[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: cvs.gedasymbols.org and gschem

karl@xxxxxxxxxxx (Karl Hammar) writes:

> The code that executes the ...-search command is in libgeda/src/g_rc.c
> (relative the top of the git repo.), in the function:
>  SCM g_rc_component_library_search(SCM path);
> I have changed that function to a wrapper around
>  int C_g_rc_component_library_search(gchar *string, gchar *name, GRegex *regex);
> which can be more easily called recursively within c. That function
> contains the main body of the former function. Its added parameters
> are "name" and "regex". regex is simply a precompiled regular
> expression matching file names ending in ".sym" (since we don't want to
> have entries that doesn't contain any symbol files). Name's function
> is described below under the code snippet.

Nack, for a number of reasons.

1) GRegex was introduced in GLib 2.14, and during the 1.7.x cycle we are
targetting GLib 2.12 or later.

2) This is an absolutely *textbook* example of the sort of thing that's
more cleanly done using Scheme (Guile has all of the necessary
functionality in the standard library).

3) I strongly recommend *not* using component-library-search because it
gives you no control over the precedence ordering of libraries when
searching for a symbol name match -- you're entirely at the mercy of the
order in which the filesystem decides to give the directories to
you. Even when that happens to be in alphabetical order, it's rarely
what you actually want.  Having it implemented in C as a core part of
libgeda functionality seems to me to send the incorrect message that
using it is a good idea.

I've been thinking of nuking g_rc_component_library_search() and
reimplementing it as a Scheme extension, and I would gladly accept a
patch that does this.



Peter Brett <peter@xxxxxxxxxxxxx>
Remote Sensing Research Group
Surrey Space Centre

geda-user mailing list