Hi,
[...]
> That's what Guile does (it attempts to locate the directory of the
> including source file), but helas, it happens after the file port
> corresponding to the including file has been relativized, which appears
> ot strip the prefix of its file name that is in the load path.
>
> e.g.: ../module/srfi/srfi-151.scm --> srfi/srfi-151.scm
To illustrate this is indeed the problem, this diff allow include to
find the source file:
--8<---------------cut here---------------start------------->8---
modified module/system/base/compile.scm
@@ -172,7 +172,7 @@
(optimization-level (default-optimization-level))
(warning-level (default-warning-level))
(opts '())
- (canonicalization 'relative))
+ (canonicalization 'none))
(validate-options opts)
(with-fluids ((%file-port-name-canonicalization canonicalization))
(let* ((comp (or output-file (compiled-file-name file)
@@ -200,7 +200,7 @@
(optimization-level (default-optimization-level))
(warning-level (default-warning-level))
(opts '())
- (canonicalization 'relative))
+ (canonicalization 'none))
(validate-options opts)
(with-fluids ((%file-port-name-canonicalization canonicalization))
(read-and-compile (open-input-file file)
--8<---------------cut here---------------end--------------->8---
This appears to be a 13 year old regression introduced with commit
0157a341577223a981d912c93b568792e9dc67e3 ("add
%file-port-name-canonicalization option"):
--8<---------------cut here---------------start------------->8---
Date: Mon Apr 19 13:14:43 2010 +0200
add %file-port-name-canonicalization option
* libguile/fports.c (%file-port-name-canonicalization): New global var.
(fport_canonicalize_filename): New helper. If
%file-port-name-canonicalization is 'absolute, then run file port
names through canonicalize_path; if it's 'relative, then canonicalize
the name, but strip off load paths; otherwise leave the port name
alone.
(scm_open_file): Use fport_canonicalize_filename.
(scm_init_fports): Define %file-port-name-canonicalization.
--8<---------------cut here---------------end--------------->8---
I'm now curious to know what was the rationale behind this change; I
gather it may have only been to avoid registering bogus source paths in
the generated .go file, as hinted by the NEWS file. If that's
confirmed, then the solution could be to find another way to accomplish
the same without touching a file port's associated file name metadata.
--
Thanks,
Maxim
