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
