On Jan 22, 2010, at 6:43 AM, Peter TB Brett wrote:
On Fri, 22 Jan 2010 13:04:11 +0000 (UTC), Kai-Martin Knaak <kmk@xxxxxxxxxxxxxxx> wrote:gschem failed to start whenever the gafrc contained a gentenv statement.(I also use the gentenv command to for the path of the local userlibrary)The Guile POSIX functions don't appear to be available on Win32. Try using $HOME in the string instead... it's possible that at some point along theline libgeda will perform environment variable substitution.
Indeed it does. For the first big project I did with gEDA (7 years ago!) I used environment variables to help the tools locate the project. So, I had:
(component-library "${EDCCD_DEV}/hardware/symbols/EDCCD")
For the next big project, I switched to using soft links to symbol
and source directories. But I wasn't completely happy with either of
these approaches, so more recent projects have just used relative
pathnames.
One potential difficulty with the environment variable approach is that it's expanded in libgeda, meaning that tools that don't get their configuration from libgeda's undocumented internals will have to evaluate the variable if they need the information from gafrc. My flatten-gafrc back end for gnetlist does not do this, so the environment variable approach won't work with it at the present time. One more thing that would be better factored out of libgeda...
John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ jpd@xxxxxxxxx _______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user