On Sun 04 Oct 2015 16:36, taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:
> $ mkdir test > $ echo '(include "test2.scm")' > test/test1.scm > $ echo '(display "foo\n")' > test/test2.scm > $ pwd > /home/taylan > $ export GUILE_LOAD_PATH=/home/taylan/test > $ unset GUILE_LOAD_COMPILED_PATH > $ guile -L test test/test1.scm ... > ERROR: In procedure open-file: > ERROR: In procedure open-file: No such file or directory: "./test2.scm" The way this works is that test/test1.scm is opened. To set the port-filename of the port, Guile uses "relative" canonicalization of the path, which will result in "test1.scm" being the port-filename, as we found test1.scm in test/. After that it all breaks down -- the intention is for `include' of a relative path to look for it relative to the dirname of the file doing the including, but (dirname "test1.scm") is ".", so it looks for "./test2.scm"... bogus. The intention of relative canonicalization is to allow for errors to be signalled relative to a path-relative file name. For example in a recent backtrace: In ice-9/psyntax.scm: 1200:36 5 (expand-top-sequence ((include "test2.scm")) _ _ #f e # #) The fact that it's ice-9/psyntax.scm comes from there. You can build the file locally and install it and it the debugging information doesn't embed the full dirname of the build tree. But, for that to work well, you really need `include-from-path' and not `include'. All of the uses of `include' in Guile itself are really `include-from-path'. And if you use `include' in a file which is in a path... well I guess that's not working. Clearly going backwards from a relative path to an absolute path is not going to work. I guess my only proposal would be to include the absolute path of a file port, in addition to the relative path. I guess that would be somewhere around the call to fport_canonicalize_filename in fports.c. Thoughts? Andy
