Thank you very much for your comments!

I'm all for having common command-line options and suffix conventions. But I wonder
how a designated command name, 'compile-r7rs' would go with the conventional

"make & make install" way. If multiple implementations provide compile-r7rs command

and a user wants to install them in standard location (e.g. /usr/bin, /usr/local/bin etc.),

there will be a conflict.

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’.

The c99 command has the same problem but I guess it's less of a problem since there

are not many popular C compilers, and these days people usually installs binaries with

some package managers, which take care of the conflict (e.g. alternative mechanism

on Debian). In Scheme, we have lots of implementations and it's typical that a user

installs them by herself.

Then it wouldn't be a problem to ask the user to create the symlink mentioned above by herself, I'd say.

I'm old school and get used to have compiler command name configurable in

Makefile, so I don't see the need of fixing compiler command name.

(Script interpreter name is slightly different, for it directly affects distribution

of ready-to-run Scheme scripts. For the compilers, though, users will

have build step and the build tool can take care of multiple selections.)

I think, providing just one command, namely ‘compile-r7rs’ is also old school. :-)
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.

Maybe the convention has changed---e.g. is it now common that installs

everything in per-implementation subdirectory instead of scattering them

in $exec_prefix/bin, $exec_prefix/lib etc? Then each implementation

doesn't need to worry about stepping on each other and just let the

higher layer of the system to do the selection. Does this srfi presume

such convention?

No, it does not. However, it also does not presume that ‘compile-r7rs’ is installed by every supporting implementation by default. The implementation just have to say, how it intends to support this SRFI (e.g. by asking the user to create a symlink by herself, etc.).

The purpose of SRFI 138 is two-fold: Firstly, to provide a single command so make portable scripts and Makefiles are possible (the opposite end of the Autotools hell, so to say), which is based, secondly, on a convention how and where library definitions are stored.

I agree that it becomes inconvenient when one switches between implementations regularly. So I propose to add something along the following lines:

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.

What do you think?

Marc