GNU bug report logs - #21613
Include messes up when compiling file in load path

Previous Next

Full log

Message #14 received at 21613 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: taylanbayirli <at> gmail.com (Taylan Ulrich "Bayırlı/Kammer")
Cc: 21613 <at> debbugs.gnu.org
Subject: Re: bug#21613: Include messes up when compiling file in load path
Date: Fri, 24 Jun 2016 16:49:05 +0200

On Sun 04 Oct 2015 16:36, taylanbayirli <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.