gnupic: Re: [gnupic] pikdev & gpsim interoperability
Subject:
Re: [gnupic] pikdev & gpsim interoperability
From:
"Scott Dattalo" ####@####.####
Date:
28 Dec 2005 18:10:29 +0000
Message-Id: <63236.71.139.4.16.1135788829.squirrel@71.139.4.16>
> hmmh, ok gpsim has an include search path it tries to use, but it looks
> like it tries to find the full-pathname inside the search path, which
> obviously wont work.
Hi John,
I just recently fixed a gpsim bug in this area. The problem was that if
there was more than one absolute path in a .cod file and gpsim was started
from within a directory different than where the .cod file was originally
assembled, gpsim would fail to load the .cod file.
I agree that absolute paths in .cod files can cause problems. There are
(at least) two ways around this. A) Don't move files around once they're
assembled (inconvenient for the user). B) Invent a .cod file path scheme
that uses OS environment variables to keep track of where .cod files may
legally reside.
gpsim attempts the latter with the -L command line option:
-L, --sourcepath=STRING colon separated list of directories to
search.
Now, I haven't used this feature in quite a while so there's a chance bit
rot has crept in. But the intent is to provide a set of directories that
gpsim can search to look for files. The logic goes something like this:
for the first .cod file loaded, gpsim will search in the current directory
(i.e. the one from which it was invoked). If it's not found then the colon
delimited list of directories specified at the command line is searched.
The first .cod file that matches is loaded. The .cod file contains
absolute paths to other files. gpsim will first attempt to load these
files at their absolute path. If this fails, then the file name is
separated from its absolute path and searched for in the directories list.
Scott
