Re: gEDA: Big changes to RC file system

[sdb-at-NOSPAMcloud9_dot_net (Stuart Brorson)]

> [ Also, Stuart, how did you handle the condition when there is a dot in 
>   a gafrc file?  Do you change the working directory to the directory
>   where the schematic lives before you read in the new gafrc?

Yes.  It now does this:

1.  Take the filename the user wants to open.
2.  Turn it into an absolute path, like /foo/bar/baz.sch
3.  From the path, figure out the directory, /foo/bar
4.  From this, create the absolute path to the local gafrc, /foo/bar/gafrc. 
5.  cd to /foo/bar
6.  read /foo/bar/gafrc while sitting in the directory /foo/bar.  This
    takes care of all the guile search path problems, like when people put
    things like (component-library "../common/symlib") or some such into
    their RC files.
7.  After that, read the file itself.
8.  Leave the directory to this directory.  This is good because the
    user expects that the next time he tries to open a schematic, the
    program will start in the last directory visited.  (I hate the Windoze
    behavior -- common for may MS apps -- where the filebrowser always
    starts at "My Documents", even if you had to browse ten levels deep
    into a networked server the last time you needed to open a doc.)

Note that I had to put conditionals into the code to prevent the
directory from being changed when you are just browsing symbols using
the sym browser's preview option.

The reason I use absolute paths everywhere is so that the program's
operation becomes independent of which particular directory you are
sitting in at any time. 

> If I understand Stuart's motivation for these changes, I suspect that
> missing symbols can be fixed by including "." in the symbol and library
> search paths.  This way, the CWD is always searched for symbols. (If the
> symbols live in a subdirectory, then use a relative path instead of an
> absolute one).

Actually, the problem is that even if you have the ".", local files
are not found.  Here's the scenario:

Dir A:
  a.sch
  gafrc  (component-libarary "./sym")
  sym/a_sym.sym

Dir B:
  b.sch
  gafrc  (component-libarary "./sym")
  sym/b_sym.sym

Currently, if you run gschem in directory A, the schematic a.sch opens
fine, and you can see a_sym.sym in the schematic.

Now, use the file browser to open ../B/b.sch.  The schematic b.sch
will be missing the symbol b_sym.sym.  This is because as currently
run, gschem never opens and reads ../B/gafrc, so it doesn't know about
../B/sym/b_sym.sym.

I have seen several different people complain about gEDA/gaf being
misconfigured [1], and I suspect that this is the problem. 
Most newbies think they can use the file browser to browse to a new
schematic and open it up.  When they try it, however, the schematics
they view appear broken if they have locally defined components.

BTW:  My changes will be totally transparent to a user who continues
to use the program in the normal, old way (i.e. sit in directory B and
open b.sch.) . . . .  as long as I have found and squashed all bugs.
That's where extensive testing comes in. . . .  Thanks to Marvin for
offering to bang on the changes!  Soon I'll unleash them on people &
you can try it out.  

Stuart

[1]  Here's one:

"All of the transistors, diodes and IC's used in the example programs
are located in a subdirector or the individual example program. There
is no info present that explains how to encourage gSchem to connect
the two. Presumably that info would in the project file used for the
project where these examples reside... only no project files are
included."

http://groups-beta.google.com/group/sci.electronics.cad/browse_frm/thread/a7e6231adad0b4ef/ecee7f0b8b40517b?q=geda+example+broken&_done=%2Fgroup%2Fsci.electronics.cad%2Fsearch%3Fgroup%3Dsci.electronics.cad%26q%3Dgeda+example+broken%26qt_g%3D1%26searchnow%3DSearch+this+group%26&_doneTitle=Back+to+Search&&d#ecee7f0b8b40517b

Another:

http://www-mdp.eng.cam.ac.uk/CD/faq.html

Browse to the bottom of that page & read the entry about gEDA.