Re: gEDA: gschem pcb-mode and RC files

[Ales Hvezda <ahvezda-at-NOSPAMseul_dot_org>]

Hi Dan,

[snip]
>So, how to proceed....  Some of the candidate options are:
>
>1)  teach pcb-mode (what I'm calling the collection of routines which 
>get loaded into gschem to make it interact specifically with pcb) how to 
>read gsch2pcb project files and extend that file format to hold any 
>extra information (if any) that might be needed by gschem.  Has the 
>advantage of being able to work with an existing gsch2pcb project file 
>that someone may have.

	The advantage of this is that there is no new file or file format
that user has to deal with.

>
>2)  use a scheme style RC file like the rest of gschem/gnetlist/gattrib 
>and teach gsch2pcb to read those instead

	The advantage of this is that all the file formats look the same.

>
>3)  #2 and have pcb-mode generate the gsch2pcb project file 
>automatically when the user asks pcb-mode to run gsch2pcb

	The disadvantage of this (and #1) is that if the gsch2pcb
format changes, this mode will have to be updated.

>
>4)  #2 and have a gsch2pcb file which is maintained seperately.  I 
>dislike this enough that I probably won't do this one.
>
>
>I'm leaning towards #1 or #3.  I'd like to avoid adding N file parsers 
>for N different modes (I'm thinking gnucap-mode, cascade-mode, etc on 
>down the road) which would suggest #3.

	Tough call.  I also like #1 or #3.  #2 looks like a lot of work
and it'll potentially break all existing project files. 

>
>If I end up with any variants of #2, is there an existing guile function 
>that sets a RC value and later reads it?  The things I saw in the 

	Nothing quite so generic exists currently in libgeda.

>system-*rc files seem to all directly call custom guile functions.  In 
>other words to add to the component library, you use
>
>   (component-library "somepath")
>
>which is customized to that function instead of something like
>
>   (append-rc-value 'component-library "somepath")
>
>where append-rc-value (which doesn't exist yet I think) could be a 
>generic function.  One of my rules with pcb-mode is anything pcb 

	I wouldn't be opposed to such an approach, but changing the
existing custom guile routines and supporting routines is quite a bit
of work.

	Are you looking to set existing rc related variables or add
new ones?  component-library isn't really an variable but rather a
function which sets internal values in library.  Ideally this should
have been just a plain scheme variable rather than a custom function.


>specific goes in pcb.scm (a single scheme file) and anything which gets 
>written in C and compiled into gschem must be generic and not pcb specific.

	I agree with the last point.  Please try to keep as little of the
mode specific code out of libgeda/gschem as possible.  

	Btw, this whole mode mechanism that you have been working on
is really cool.  I can also see the many more modes being written down
the road.

								-Ales