Re: gEDA-user: gschupdate always eats symbols

[Ales Hvezda <ahvezda@seul.org>]

Hi Stuart and all,


[snip]
>I notice that there is a proliferation of RC files occuring here.  I
>am guilty of this too, since gattrib also wants an RC file called
>gattribrc to live in the share/gEDA directory.  Now we will have the
>following RC files:  gschemrc, gnetlistrc, gattribrc, gschlasrc,
>gsymcheckrc.  Have I forgotten any others?   

	
	Don't forget about all the system-*rc files and the ones in
~/.gEDA

I've noticed this as well.  Several possibilities:

	1) Leave things as they are.  This allows for max flexibility with
	   the unfortunate increase in rc management complexity.

	2) Add another rc file to the mix, commonrc (which would be consistent
	   with the system-commonrc file).  Also searched for in ~/.gEDA and
	   the local directory.  You can do this yourself today with the
	   "load" scheme mechanism.

	3) Essentially consolidate everything into one rc file, but still
	   support all the current rc files and provide a new rc filename
	   which is read in all the files.

	4) Eliminate all the *rc files and consolidate everything in one
	   rc file.  gedarc or gafrc or such.

#1, #2, and #3 are the most backwards compatible.  #4 is the least
backwards compatible.  If anybody has any further ideas/comments, please
let me know.


>On the subject of RC files, I am also getting 
>e-mails from folks who are having problems reading/parsing the gattrib
>RC file because they have placed statements in it which make Guile ill
>under gattrib, but are fine in other gEDA progs.  The point here is
>that different progs seem to want different things in the RC files;
>there is no uniformity to their use.  Or am I wrong again?  :-)  


	Yes, you are correct.   There are gnetlist specific commands that
can only go into gnetlistrc files and likewise gschem specific commands that
can only go into gschemrc files.


>Since the most important thing in the RC file is the pointer to the
>symbol libs, I wonder if a better approach moving forward would be to
>consolidate the files into one?  Or is there an architectural reason
>to have multiple RC files?


	Flexibility and when I first wrote gschem and then gnetlist, I did
not want to have to support gschem specific keywords in gnetlistrc
files etc...  

	I'm not against consolidation as that would simplify the programs
a bit (move keyword support/registration routines into libgeda) as all
rc keywords would be shared by all libgeda programs.  Hmmm.. there might
be some serious merit to this.

								-Ales