import path vs CLASSPATH

import path vs CLASSPATH

[Peter Lane]

(This is not really a question, but more an observation - perhaps a 
curious query.)

I found there's a difference between import path and CLASSPATH, with 
respect to how kawa locates libraries: "import path" seems to be 
relative to the input program, whereas CLASSPATH is relative to the caller.

The Kawa documentation says "The default search path is |"."| - i.e. 
just search relative to the current root"; I was expecting the current 
root to be the directory where I ran kawa, but it appears to be the 
location of the program.

e.g. if I use -Dkawa.import.path="./*.sld", library files are found only 
in the same directory as the program I run:

 > kawa --r7rs -Dkawa.import.path="./*.sld"  dir/program.sps

only finds libraries within dir, and fails if the required library is in 
the current (caller's) directory.  (If the libraries are in 'dir' the 
import is unnecessary: kawa --r7rs dir/program.sps will find 
dir/mylibrary.sld.)

However, if I compile the library: > kawa -C mylibrary.sld, and set 
CLASSPATH=.

then the .class file for the library will be found relative to the 
caller's directory.


I came across this because I'm working with a Java library and writing 
lots of scripts for different tasks.  Some common functions are bundled 
up in a library, for them all to use.  The library sits in the directory 
I run kawa from, and child directories hold the scripts.  I've set my 
run script to use the import path:
-Dkawa.import.path="$(cd "$(dirname "$0")" ; pwd)/*.sld"
which finds the script's path and sets up an absolute path to the import 
location.

Now I'm aware of this, it's not a problem, but it did confuse me for a bit.

--
Peter Lane
http://peterlane.info/scheme.html

Re: import path vs CLASSPATH

[Per Bothner]

On 02/08/2017 10:36 AM, Peter Lane wrote:
> (This is not really a question, but more an observation - perhaps a curious query.)
>
> I found there's a difference between import path and CLASSPATH, with respect to how kawa locates libraries: "import path" seems to be relative to the input program, whereas CLASSPATH is relative to the caller.
>
> The Kawa documentation says "The default search path is |"."| - i.e. just search relative to the current root"; I was expecting the current root to be the directory where I ran kawa, but it appears to be the location of the program.

Depends what you mean by "the program".  The path is relative to the *importing* module.
I.e. the source file that contains the import or require form.

The manual does say:

     For example the source to a library with the name (x y) that compiles to a class x.y
     might be a file named /a/b/x/y.scm. Then the current root would be /a/b/ - that is the
     directory that results from removing the library name suffix from the file name.

     More generally: assume the current module has N name components. For example the name
     (x y) (with the class name x.y) has 2 components. The current root is what you get when
     you take the current file name (say "/a/b/c/d.scm"), and remove everything after the N’th
     slash ("/") from the end (say "c/d.scm"; what remains (e.g. "/a/b/" is the current root.
     (If the current input source is not a named file, use the value of (current-path) with a "/" appended.)

This is how include files work in C, for example.

Perhaps changing "If the resulting filename is relative, then it is resolved relative to the current root."
adding ", which is derived from the name of the source file containing the import/require"
might make it clearer?
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: import path vs CLASSPATH

[Peter Lane]

On 08/02/17 21:41, Per Bothner wrote:
> Depends what you mean by "the program".  The path is relative to the 
> *importing* module.
> I.e. the source file that contains the import or require form.
Yes, this makes more sense now.  It is quite logical, although I did get 
caught out even after looking at the manual - by thinking the 
import.path was analogous to CLASSPATH.

> Perhaps changing "If the resulting filename is relative, then it is 
> resolved relative to the current root."
> adding ", which is derived from the name of the source file containing 
> the import/require"
> might make it clearer?
That would help make things clearer.  I also think the point should be 
flagged up earlier - the third paragraph could include a similar phrase: 
"Each path element is combined ... to produce a filename; relative path 
elements are /relative to the source file containing the import/require/."

--
Peter Lane
http://peterlane.info/scheme.html