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
<[email protected]> 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 user
library)
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 the
line 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/
[email protected]
_______________________________________________
geda-user mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
