From: Daphne Preston-Kendal <dpk@nonceword.org>
To: 66046@debbugs.gnu.org
Subject: bug#66046: Relative includes in R7RS define-library seem broken
Date: Sun, 17 Sep 2023 10:22:20 +0200 [thread overview]
Message-ID: <6C8500AC-6352-4849-A2C9-2DFEB34F21D5@nonceword.org> (raw)
A standard layout for R7RS libraries is to have an .sld file
containing the library import and export declarations with a parallel
.scm file with the same name in the same directory, which the .sld
file (include ...)s.
E.g. lib/dpk/mylibrary.sld:
(define-library (dpk mylibrary)
(import (scheme base))
(export make-frob #;etc)
(include "mylibrary.scm"))
and then mylibrary.scm is also in the same lib/dpk directory as
mylibrary.scm and includes the actual code.
Guile supports looking for .sld files before .scm files if started in
--r7rs mode. However, in this case, it will not find the .scm file if
it’s included from the .sld file.
Starting Guile with: guile --r7rs -L './lib'
or by setting the GUILE_LOAD_PATH environment variable, (in both cases
with absolute paths or relative ones) and attempting to import
libraries such as this results in a file not found error for the
included .scm file, e.g.:
scheme@(guile-user)> (import (chibi shell))
;;; note: source file /Users/dpk/Projects/r7rs/lib/chibi/shell.sld
;;; newer than compiled /Users/dpk/.cache/guile/ccache/3.0-LE-8-4.6/Users/dpk/Projects/r7rs/lib/chibi/shell.sld.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /Users/dpk/Projects/r7rs/lib/chibi/shell.sld
;;; WARNING: compilation of /Users/dpk/Projects/r7rs/lib/chibi/shell.sld failed:
;;; In procedure open-file: No such file or directory: "chibi/shell.scm"
scheme@(guile-user)>
Curiously, including a file which *actually* doesn’t exist results in
two different, one of which correctly reports the full path of the
file it’s purportedly trying to include:
scheme@(guile-user)> (import (chibi shell))
;;; note: source file /Users/dpk/Projects/r7rs/lib/chibi/shell.sld
;;; newer than compiled /Users/dpk/.cache/guile/ccache/3.0-LE-8-4.6/Users/dpk/Projects/r7rs/lib/chibi/shell.sld.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /Users/dpk/Projects/r7rs/lib/chibi/shell.sld
;;; WARNING: compilation of /Users/dpk/Projects/r7rs/lib/chibi/shell.sld failed:
;;; In procedure open-file: No such file or directory: "chibi/wonderpants.scm"
While compiling expression:
In procedure open-file: No such file or directory: "/Users/dpk/Projects/r7rs/lib/chibi/wonderpants.scm"
scheme@(guile-user)>
So this smells like a bug where the part of the R7RS library code
looks in the wrong place and fails, but after it’s already failed, a
second part of the code looks again in the correct location and
reports another error if the file really didn’t exist. This is a
strange hypothesis but it’s the only thing I can think of.
Changing the path in the include declaration to be absolute fixes the
problem, but then it no longer works on other people’s machines.
Guile version: 3.0.9
installed from nix-unstable
next reply other threads:[~2023-09-17 8:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-17 8:22 Daphne Preston-Kendal [this message]
2023-11-06 18:31 ` bug#66046: Relative includes in R7RS define-library seem broken Timothy Sample
2023-11-06 18:48 ` Maxim Cournoyer
2023-11-06 19:57 ` Maxim Cournoyer
2023-11-07 4:42 ` Maxim Cournoyer
2023-11-10 3:36 ` bug#66046: [PATCH 1/2] tests: Add new compile-file tests Maxim Cournoyer
2023-11-10 3:36 ` bug#66046: [PATCH 2/2] ice-9: Fix 'include' when used in compilation contexts Maxim Cournoyer
2023-11-11 11:58 ` bug#66046: Relative includes in R7RS define-library seem broken Amirouche
2023-11-14 13:57 ` Maxim Cournoyer
2023-11-18 22:56 ` Maxim Cournoyer
2023-11-22 16:11 ` bug#66046: [PATCH v2 1/3] libguile/fports.c: Remove extraneous include Maxim Cournoyer
2023-11-22 16:11 ` bug#66046: [PATCH v2 2/3] tests: Add new compile-file tests Maxim Cournoyer
2023-11-22 16:11 ` bug#66046: [PATCH v2 3/3] ice-9: Fix 'include' when used in compilation contexts Maxim Cournoyer
2023-11-22 16:17 ` bug#66046: [PATCH v3 1/3] libguile/fports.c: Remove extraneous include Maxim Cournoyer
2023-11-22 16:17 ` bug#66046: [PATCH v3 2/3] tests: Add new compile-file tests Maxim Cournoyer
2023-11-22 16:17 ` bug#66046: [PATCH v3 3/3] ice-9: Fix 'include' when used in compilation contexts Maxim Cournoyer
2024-09-14 1:34 ` bug#66046: [PATCH v4 1/3] libguile/fports.c: Remove extraneous include Maxim Cournoyer
2024-09-14 1:34 ` bug#66046: [PATCH v4 2/3] tests: Add new compile-file tests Maxim Cournoyer
2024-09-14 1:34 ` bug#66046: [PATCH v4 3/3] ice-9: Fix 'include' when used in compilation contexts Maxim Cournoyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6C8500AC-6352-4849-A2C9-2DFEB34F21D5@nonceword.org \
--to=dpk@nonceword.org \
--cc=66046@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).