My main concern is that how I, as a developer of Gauche, make the Gauche
distribution conforming this srfi.  I hesitate to let Gauche install
${execi_prefix}/bin/compile-r7rs, for it may overwrite some other Scheme.
I could provide configure option but that's one more burden for the user.

It'll be the best if I can just say "we install srfi-138 compatible command
${exec_prefix}/bin/compile-gauche.  It's up to other tools that make a 
symlink /usr/bin/compile-r7rs to compile-gauche."

If this srfi can make such use case explicit, it'll be great.

My preference is to make it clear that this srfi is specifying these two *distinct* components:

- A spec of command-line arguments each conforming implementation must support.
  An implementation provides such interface can be said to support srfi-138.

- A spec of meta tool that may invoke one of such implementation.
  (This specifies the name "compile-r7rs" and possibly the interpretation of COMPILE_R7RS
  env variable)
  This is not a Scheme implementation by itself, but rather an auxiliary utility.

For the user's convenience, an implementation may bundle these two, but conceptually
they are in separate layers.
(To avoid confusion, we might be better to decide some term to cover the latter layer,
which can also support common name for the script, etc.)



On Thu, Jul 7, 2016 at 1:31 AM, John Cowan <xxxxxx@mercury.ccil.org> wrote:
Marc Nieper-Wißkirchen scripsit:

> A typical ‘make install’ could install a, say, ’compile-gauche’ by
> default that has the same calling conventions as ‘compile-r7rs’
> would. The system administrator may then provide a symlink to
> ‘compile-r7rs’. Or, an implementation with ‘./configure’ could
> provide a switch to this configuration script such that when it is
> set, the above symlink is created by ‘make install’.

I think something like the above language should be included in
the next draft of the SRFI.

> Under UNIXy operating systems, there usually tends to be one command
> for every task, say, ‘make’, whether the command is provided by GNU
> make, or BSD Make, or whatever.

Provisions are often made so that they won't step on each other, however.
This is especially important when they are to some degree incompatible.
On BSD systems, GNU make is often installed as gmake, and GNU make will
read from GNUmakefile instead of Makefile if it finds it.  (Chicken, as
it happens, requires GNU make, and takes advantage of this feature by
putting only an error message in Makefile and the real make commands in
GNUmakefile.)

>    There may be more than one command on the host system that supports
>    the interface of the ‘compile-r7rs’ command in this SRFI. As at most
>    one ‘compile-r7rs’ binary in the path would be executed, a user who
>    wants to exploit the interface described by this SRFI is recommended
>    to employ the following convention: If the environment variable
>    COMPILE_R7RS is set, it is supposed to hold the pathname of the
>    binary to be called instead of the generic ‘compile-r7rs’.
>    Otherwise, the user is supposed to invoke ‘compile-r7rs’ directly.

I suggest rather that this be a required feature of compile-r7rs itself;
that is, if COMPILE_R7RS is set, and the pathname in it is *not*
the pathname of the running compile-r7rs, then it execs the specified
pathname, passing it all its arguments.  That way, it doesn't matter
which one is on $PATH, you can get any Scheme you want by setting
COMPILE_R7RS properly.

This is analogous to the way Perl treats #! lines: if the script begins
with a #! line that does not contain the string "perl", then it will exec
the named program instead.  So if the file begins with "#!/usr/bin/awk",
you can run it using Perl and it will invoke your system awk.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Well, I have news for our current leaders and the leaders of tomorrow:
the Bill of Rights is not a frivolous luxury, in force only during
times of peace and prosperity.  We don't just push it to the side
when the going gets tough.  --Molly Ivins