Re: try-using-libtool-name

[Jim Blandy <jimb@red-bean.com>]

> Slipping into philosophy mode here, if guile really is supposed to
> be universal then the true core of guile has to be as small as
> possible.

This is exactly right, I think.

The long-term goal is as follows:

Produce a smaller Guile core which implements R5RS and a module
system, with dynamic library linking support, and nothing else.  Move
all other functionality into libraries.

This core will not require any support files to be installed; you can
just copy the executable to a new machine, and it will work.  In
theory this doesn't matter, but there are a lot of small apps (like
XaoS) that could use Guile, but for which the tangle of
${prefix}/share installation is overkill.

This core will be designed to be copied into other distributions, so
that people can distribute Guile-based applications without requiring
their users to download and install Guile first.  Certainly,
encouraging people to incorporate Guile into their distributions will
cause problems with version skew, but it's better than having them
choose not to use Guile at all.  And we can probably find some middle
ground, between encouraging people to track the Guile dist, and
encouraging people to copy it everywhere.

(This is the reason for separating out the syscalls, etc. from the
Guile core: having a big shared library is no problem, but we want to
make the boundaries more apparent for people who are going to slice
and dice.)

> My question is why all of these are part of the guile-core
> distribution and why they are all integrated into libguile...
> surely this is exactly the sort of thing we want dynamic
> libraries for (or even static for that matter, anyhow not
> part of libguile).

Yep.  It's a Simple Matter Of Programming.