Re: gEDA: Big changes to RC file system

[sdb-at-NOSPAMcloud9_dot_net (Stuart Brorson)]

Hi Ales --

[. . . . snip . . . .]

> >I also refactored code in all the programs which rely upon these
> >functions in libgeda.
> 
> 	This is probably a good idea, however, I never intended the user
> to read in multiple different project gafrcs while running a single
> instance of gschem, so I worry about the following related scenarios:
> 
> 1) Picture that you have multiple schematics in muliple directories
> (different projects or different revisions of the same schematic)
> and you start opening them up and the local gafrc files get read in.
> What happens if the gafrc themselves set component-library paths which
> break the schematic?  Is this a problem?

Reading in two files works this way:

1.  set the directory to that holding the new file A.
2.  read in the local gafrc.
3.  read in the schemtic A.sch.
4.  set the directory to B's directory
5.  read in the local gafrc
6.  read in B.sch.

Now, if you have the same symbol name in both A's and B's local lib,
then B will be instantiated using A's symbol (or vice versa, depending
upon search order).  This might cause breakage, but it is a normal,
everyday problem.

The alternative is worse, IMHO:  A newbie tries out gEDA, reads A.sch
successfully, but browses over to B, tries to read it in, but finds it
broken.  The newbie can't figure out why B is broken, so he abandons
gEDA altogether.

> Another way to state the above:
> 
> 2) Unless I have forgotten, but reading in a gafrc affects every
> loaded schematic, so schematic A has its gafrc loaded (with its own
> component-libraries), then the user loads schematic B and has its gafrc
> loaded.  Now the running gschem has two sets of component-libraries
> which might clash.  Again, do we care about this problem?

It is a possibility, but is a normal issue with any piece of software
which searches libraries to place parts or symbols.  The power user
learns to keep symbols named uniqely if he has many different local
libraries.

Also, note that in your scenario, schematic A has already been loaded
and displayed, so nothing happens to A.  Schematic B might have a part
read out of A's library if you have identically-named parts in both
libs.  If you have identically-named symbols which show different
graphics, then the problem lies with you, and not the program.

FWIW:  I have tested the changes on my machine where I have several
schematics with different local libs, but the local libs have many
identically-named components.  I have seen no breakage; the
identically named parts are identical; I have just copied them from
one directory to another. 

I also name the local symbol library "./sym" in several directories.
In testing, gschem happily reads both in, and displays both in the
symbol browser.  It is kind of stupid to have two directories called
"sym" right next to each other, but that is my stupidity, not
gschem's!  :-)  

> Probably for the casual user, this change won't be too much of a problem,
> however I worry about the experienced user . . . .

The experienced user will see no change if he continues to use
gEDA/gaf as in the past (i.e. sit in directory A and work on a.sch).
If he browses over to directory B and opens up B.sch, then the libs on
B's search path will appear in his sym lib browser & he will be able
to use them on either A or B.

Of course, if he places a component from B's lib on schematic A, then
closes out & later re-opens A only, the B component won't be there.  I
expect the power user will know enough about how libraries work to
avoid this problem.

> . . . . . . . .who does something and all
> of the sudden gschem thinks it's being smart and does something really
> stupid or rather unexpected.  I'm probably just being paranoid...

As I always tell the folks in the marketing group at work [1]: That's
why we do extensive testing before releasing the product on cutomers! 

Stuart

[1]  When they want to send a barely-hacked-together, engineering
alpha-prototype product to customers, and are mad that testing places
us "behind schedule".