From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by sourceware.org (Postfix) with ESMTPS id DD8943861836 for ; Sat, 6 Feb 2021 17:04:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DD8943861836 Date: Sat, 06 Feb 2021 17:04:31 +0000 To: "J. Vincent Toups" From: spellcard199 Cc: "kawa@sourceware.org" Reply-To: spellcard199 Subject: Re: Behavior of (import ...) in R7RS define-library forms Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, FREEMAIL_REPLYTO_END_DIGIT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: kawa@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Kawa mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2021 17:04:49 -0000 Hello. I'm far from being an expert (and not using Java nor Kawa atm) but after trying to reproduce your project structure I think it's a problem of how "kawa.import.path" is resolved. 2 things seem to work: 1) If you can, instead of -Dkawa.import.path=3D"./src/*.scm" use an absolute path (e.g.): -Dkawa.import.path=3D"/home/user/development/project_name/src/*.scm" 2) If you must use a relative path: 1. Use: -Dkawa.import.path=3D"./*.scm" 2. Start repl from inside the src directory I just skimmed rapidly through it and I may be wrong but I think the section "19.6.2 Searching for source files" in the Kawa manual expains how this works. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Friday 5 February 2021 15:21, J. Vincent Toups via Kawa wrote: > I have two r7rs-style libraries, one of which depends on the other, > located in the following filesystem structure: > > src/lib/shadchen-helpers.scm > src/lib/shadchen.scm > > In principle, shadchen-helpers isn't useful on its own - it provides > some helper material for the shadchen library. > > The library definitions look like this: > > $ find src/ -iname "*.scm" | grep lib | xargs head -n 2 > =3D=3D> src/lib/shadchen-helpers.scm <=3D=3D > (define-library > (lib shadchen-helpers) > > =3D=3D> src/lib/shadchen.scm <=3D=3D > (define-library > (lib shadchen) > > So if I start a repl like this: > > $ java -jar lib/kawa.jar -Dkawa.import.path=3D"./src/*.scm" > > Kawa can find the libraries if I do an import: > > #|kawa:1|# (import (lib shadchen-helpers)) > > The above works fine. However, in a fresh interpreter: > > #|kawa:1|# (import (lib shadchen)) > /home/toups/work/games/jmonkey3d-lacraw/src/lib/shadchen.scm:9:4: > unknown library (lib shadchen-helpers) > /home/toups/work/games/jmonkey3d-lacraw/src/lib/shadchen.scm:110:6: > warning - no declaration seen for pattern-bindings-equal? > /home/toups/work/games/jmonkey3d-lacraw/src/lib/shadchen.scm:117:6: > warning - no declaration seen for all-identifiers? > > The import fails because the library reference to shadchen-helpers > fails to resolve. That reference in `shadchen.scm` looks like this: > > (import (except (kawa base) match) > (kawa lib std_syntax) > (srfi 28) > (rnrs sorting (6)) > (rnrs hashtables (6)) > (lib shadchen-helpers)) > > I have noticed that importing shadchen-helpers at the repl first and > then importing shadchen works. I would guess because importing the > shadchen-helpers library compiles that library and then the import > form in the r7rs define-library can then find the compiled artifact. > > But doesn't it make sense for the import form in shadchen to trigger > the compilation of shadchen-helpers so that it behaves the same as a > top-level import? Is there any way I can get this behavior? It seems > limiting to interactive development to have to have either a build > process or a script to import all libraries despite an explicit > dependency graph existing in the form of the import statements in the > library definitions? > > I'm relatively new to Kawa and a little rusty in Java (long time > Schemer, though) so maybe I'm missing something. > > -V