[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gEDA: gschem pcb-mode and RC files



Ales Hvezda wrote:
> Hi Dan,
> 


>>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.

right.  I'm not a big fan of that but on the bright side since pcb-mode 
and gsch2pcb get into snapshot releases at the same time we shouldn't 
have problems of the 2 pieces being out of sync.

>>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.

I'm looking for new ones.  Basically any variables which would be 
specific to a particular mode.  As near as I can tell, all the rc file 
stuff is like component-library in that they're functions.

I also wonder if I can cheat and make the project file look like this:

(define pcb:schematic-files list("schematic1" "schematic2" ...))
(define pcb:gsch2pcb-command "/usr/local/bin/gsch2pcb")

etc.

and then simply execute the file and look at the variables.  That 
wouldn't take any extra parser since it would just use the guile parser.

It does provide a nice way for the user to be able to do some totally 
wrong things like redefining internal things which should not be redefined.

> 
> 
> 
>>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.  

I think I've been able to follow this rule 100% so far.  It is true that 
I've added things which are only used currently by pcb-mode but they are 
not specific to pcb-mode.  For example (gschem-msg "a message for the 
user") pops up a message dialog box.


> 	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.
> 

thanks!  I am hoping that this is the path to gschem remaining a generic 
and flexible tool and also being able to work more closely with 
simulators and layout tools.

-Dan