Snow-Chibi is a local package manager, not a system one. It can install
Scheme packages into system but they are not managed by system package
manager like dpkg, RPM, pacman, ports, etc.
Traditionally (and in accordance with Filesystem Hierarchy Standard),
/usr/local hierarchy should be used for local administrator installs --
and that's what Snow-Chibi provides.
Let's make sure that Snow-Chibi installs snowballs into /usr/local
hierarchy even if Chibi is compiled for installation into the system,
with PREFIX=/usr. Introduce a distinct bunch of variables holding paths
to library installation directories, with "SNOW" prefix:
- SNOWPREFIX - default prefix for Snow-installed stuff
- SNOWLIBDIR - custom libraries required for Snow itself
- SNOWSOLIBDIR - shared libraries required for Snow itself
- SNOWMODDIR - Snow installs Scheme modules here
- SNOWBINMODDIR - Snow installs native libraries here
All of these are set to /use/local by default, just as they are now.
However, they are not affected by regular PREFIX, LIBDIR, MODDIR, etc.
which affect only libraries bundled with Chibi.
And in order for these to work, they need to be added into the current
module path so that they can be used in parallel with system libraries.
Furthermore, we need to tweak "get-install-library-dir" function to use
those paths instead of hardcoded "/usr/local/lib" by default. Introduce
a new helper "get-install-library-dirs", similar to "get-install-dirs".
It will look up the correct installation directories in current module
path, giving preference to the ones with "/lib" in them.
With these defaults, Snow will install Scheme modules into
/usr/local/share/snow and native libraries go into /usr/local/lib/snow,
similar to how built-it libraries are installed into
/usr/local/share/chibi and /usr/local/lib/chibi is used for native code.
Of course, this can be overriden at build time by setting SNOWPREFIX or
individual SNOWMODDIR, SNOWBINMODDIR variables.
Both SOLIBDIR and BINMODDIR install into $(PREFIX)/lib which is the same
value as LIBDIR -- the traditional name of the directory for installed
libraries. Current duplication is fine for the default installation
(with PREFIX = /usr/local) but it does not play nicely with systems
supporing multiple architectures.
For example, Debian systems allow the users to install libraries for
multiple architectures simultaneously: e.g., 32-bit and 64-bit libraries
for AMD-64 CPUs go into separate directories:
- 64-bit: /usr/lib/x86_64-linux-gnu/libchibi-scheme.so.0.8.0
- 32-bit: /usr/lib/i386-linux-gnu/libchibi-scheme.so.0.8.0
Other Linux systems (Red Hat family) use different paths like /usr/lib64
and /usr/lib, but the general idea is the same.
In order to achive this, packaging toolchain supplies appropriate value
of LIBDIR which takes care of these details more or less automagically.
However, with Chibi you currently need to additionally override SOLIBDIR
and BINMODDIR to have all the libraries installed into multiarch-enabled
locations. While definitely doable, it's not convenient.
Redefine SOLIBDIR and BINMODDIR in terms of LIBDIR so that you only need
to override LIBDIR to get the packaging correctly. This does not change
the default installation paths and it is still possible to override
these values individually if necessary.
- Makefile.libs: changed definition of LN to LN -sf, so can be overridden
with LN=cp on systems with no symlinks; introduced LDCONFIG, so can be
overridden if desired.
- Makefile: changed uses of $(LN) -sf to $(LN); replaced two occurrences
of ldconfig by $(LDCONFIG); suppress install of $(IMAGE_FILES) if variable
is empty.
Note: the IMAGE_FILES change was to enable Chibi to be compiled on GNURoot+Android,
and can be reasonably reverted if an alternate way of dealing with image files
is chosen.
Adding these options will simplify the FreeBSD port of chibi-scheme
(https://freshports.org/lang/chibi-scheme) because I can get rid of
most of the custom patches currently needed. In FreeBSD pkg-config
files need to be installed into libdata/pkgconfig. INSTALL_EXE
provides a hook for replacing the normal 'install' program with
'install -s' for stripping the binaries/libraries. Adding these
options should have no impact on the default build process.
