gEDA-dev: Re: geda symbols

[Peter TB Brett <peter-at-NOSPAMpeter-b_dot_co_dot_uk>]

(Copying geda-dev on private mail conversation).

On Friday 27 April 2007 02:42:25 you wrote:
> 15:05 <peterbrett>	I had an idea, which was to make it possible to add
> *programs* to the libgeda symbol search list
>
> pcb has supported this for a long time ;)
>
> One of the side effects of the way pcb ran m4 to generate footprints at
> run time instead of build time is that
>
> qfp.inc has at the end:
>
> define(`PKG_MENU_QFP',
>          `esyscmd(qfp-ui "$1" "`$2'" "$3")'
> )
>
> the m4 "esyscmd" function is like system() in c.  qfp-ui is a graphical
> qfp footprint builder.

I am aware of this.  It also sucks as a model for symbol generation, because 
it's not reproducible.  You'd have to fiddle with a GUI every time you want 
to instantiate the symbol, which would include netlisting.  You could embed 
it, but then it wouldn't update automatically if you found a bug in the 
symbol.

What I had in mind was the commands as frontends to various databases of 
parts, with the "symbol name" (e.g. XC3S1500-FG456-C-a, for the first bank of 
IOs on a 456-ball array packaged Spartan 3 1500 FPGA) as the primary key.  A 
good example of a very simple database would be the existing file-based 
search system.

The interface I had in mind was something like the following (all search 
commands must support it):

  symcmd -f SYMNAME            output the symbol SYMNAME on stdout, or return
         ( --fetch )           non-zero exit status if not found.

  symcmd -l [ CATEGORY ]       list the available symbols and/or categories
         ( --list )            within the given category path on stdout, or
                               return non-zero exist status if category not
                               found.  Note this enables multiple levels of 
                               hierarchy in the component picker, which can be
                               loaded on demand.

  symcmd -q QUERYSPEC ...      query top-level attributes in symbols, listing
         ( --query )           matching symbols on stdout (QUERYSPEC is an 
                               ATTRIBUTE=PATTERN pair).  This is an optional
                               command because it would still be possible to
                               pick & use symbols from a db without it.

I don't believe that adding initial support from this in gschem (loading from 
commands and single-level categorisation in the component picker from 
commands) would be too difficult.  Adding query and on-demand category 
loading would be more difficult.

Once this is implemented, the current static library system should probably be 
rerigged to be accessed via a command -- there's enough symbols in there that 
searching them would be useful.  However, we need to keep the use of static 
libraries available for e.g. one-off symbols used for a single project.

Cheers,

Peter

-- 
Fisher Society committee                    http://tinyurl.com/o39w2
CUSBC novices, match and league secretary   http://tinyurl.com/mwrc9
CU Spaceflight                              http://tinyurl.com/ognu2

v3sw6YChw7$ln3pr6$ck3ma8u7+Lw3+2m0l7Ci6e4+8t4Gb8en6g6Pa2Xs5Mr4p4
  hackerkey.com                                  peter-b.co.uk

PGP signature

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