GNU bug report logs - #66046
Relative includes in R7RS define-library seem broken

Previous Next

Full log

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Timothy Sample <samplet <at> ngyro.com>
Cc: 66046 <at> debbugs.gnu.org, Daphne Preston-Kendal <dpk <at> nonceword.org>
Subject: Re: bug#66046: Relative includes in R7RS define-library seem broken
Date: Mon, 06 Nov 2023 14:57:54 -0500

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

Previous Next

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