But I"d like to stress the fact that run-time and compile-time file
locations may differ, also things like dynamic loading vs static
linking come into play. In the end this is a build issue, not necessarily
a question of run-time semantics.
Sorry, I was being ambiguous. The natural strategy when dealing with
R7RS is to compile each .sld file [i.e. each (define-library ...) form]
into one .o or .so file, traversing any (include "...") files at compile
time, not at runtime, so that the code in the included files becomes
part of the object code corresponding to the .sld file.
So you'd check foo.sld into git, and compile it and its dependencies
into foo.so for dynamic linking, or into foo.o for static linking.
Actually, the physical locations of code are secondary, as long as libraries
are found, resolved and evaluated properly. Once again, I can not help but point
towards "csm"[1], as a natural and convenient (yet, apparently sadly ignored),
tool-based solution to this problem.
I wasn't aware of the tool. Looks like good thinking went into it!
For portable code, the main obstacle in practice is that a different
wrapper file is required per each standard and/or implementation. For
example, R6RS and R7RS typically require separate .sls and .sld files.
(R6RS has many features that are not in R7RS-small, but a lot of useful
code would be easily portable if it weren't for the different (library
...) vs (define-library ...) wrappers, as well as the
implementation-specific module wrappers in Scheme implementations that
predate R6RS. It would help a lot if one .sld file could cover all
R7RS-capable implementations, even if (cond-expand ...)s have to be
written inside the file.
Reading csm's manpage, it seems to handle .sld files just as well as
other kinds, but since it's not part of core Chicken, people tend to
write eggs and other code in .scm files using (module ...) forms which
complexifies the task of porting that code.
Here's an example of a real library that's provided as both a Chicken
egg and a R7RS (and R6RS) library in the same git repo:
https://gitlab.com/weinholt/packrat. The implementation code that does
the heavy lifting is shared among all three (packrat-r5rs.scm) but the
library wrappers are all different (), and there's a little magic in
packrat.egg and packrat.setup to enable things.
