Am Dienstag, 4. Januar 2005 14:06 schrieb Stuart Brorson:
> I have built a private copy of libgeda implementing my search path:
>
> $system/gafrc
> $home/gafrc
> ./gafrc
> $system/gschemrc
> $home/gschemrc
> ./gschemrc

That's nice. I like it that way.

>
> It works fine.  The only problem is that I get a warning when it tries
> to find the "required system-gafrc" file:
>
> Did not find required system-gafrc file
> [/usr/local/geda/share/gEDA/system-gafrc] Did not find optional
> ~/.gEDA/gafrc file [/home/sdb/.gEDA/gafrc]
> Read local gafrc file [./gafrc]
> Read system-gschemrc file [/usr/local/geda/share/gEDA/system-gschemrc]
> Did not find optional ~/.gEDA/gschemrc file [/home/sdb/.gEDA/gschemrc]
> Did not find optional local gschemrc file [./gschemrc]

That's not a problem, that's a feature. During every startup I can check what 
rc files are read. Leave it like it is!!


>
> However, differentiating between optional and required files can be
> handled in another way than what we do now.
>
> I like Peter's suggestion that the system-commonrc become the
> system-gafrc.  This is a good first step on the road to migrating
> towards using gafrc everywhere & deprecating the old g[schem | netlist
>
> | attrib | symcheck]rc system.  It does require some changes to the
>
> *rc.in files -- particularly in the symbols directory -- but that I
> don't mind doing.
>
> I don't think the old system should go away; that might cause breakage
> of legacy schematics.  However, we can incorporate the new gafrc
> system while deprecating the old system for new designs.

Please leave the old gschemrc, gnetlistrc ..... . They are necessary for 
setups of a single program only.

>
> One question:  If I make changes to libgeda, I would like to have
> folks test my stuff.  Are there any volunteers out there who are
> willing to get stuff out of CVS, build it and test it when I post an
> update?  Peter?

Ok, I can do that.

>
> In general, it would be a good thing to have a few beta testers who
> can verify that the code in CVS builds reliability.
>
> Stuart
>



Reply via email to