Re: Managing Guile and extensions versions

From: Vorfeed Canal <vorfeed.canal@gmail.com>
Subject: Re: Managing Guile and extensions versions
Date: Tue, 4 Oct 2005 15:06:28 +0400	[thread overview]
Message-ID: <6efab2350510040406o10b238a2m54543ea373cdd7f5@mail.gmail.com> (raw)
In-Reply-To: <87fyrj8ipf.fsf@zip.com.au>

On 10/3/05, Kevin Ryde <user42@zip.com.au> wrote:
> Vorfeed Canal <vorfeed.canal@gmail.com> writes:
> >
> > Easy: there are no easy
> > way to install two snaphots of GUILE side-by-side. So such a need is
> > quite real (unless development will be frozen totally).
>
> The developers manage.  Even I manage to run 3 versions.
>
And this proves... exactly what ? Your ability to jump through hoops ?

When computers are concerned there are rarely exist a case where
"something is impossible" - usually it's "quite hard and error-prone".
Environment variables are exactly that: hard and error-prone (hard:
since they do different things on different systems and error-prone
since you must specify installation path two times in different
places: manual information duplication is the great way to
frustration).

> [guile-gnome env var setups]
>
And then add some program where guile is embedded as library to the
mix and see the mess where two interpreters are loaded from two
libraries. Been there seen that, no need to repeat the experience.

> > is *NOT* a good solution.
>
> It doesn't seem terrific to me either.  scm files outside any known
> location will have to have a load-path addition, but after that it
> oughtn't need to mung LD_LIBRARY_PATH for private C code.

Exactly. Why the hell scm files are managed via scheme variable but C
modules - via system-dependent variable! LD_LIBRARY_PATH is linux'ism,
it can be DYLD_LIBRARY_PATH LD_LIBRARY_PATH, LIBPATH, LIBRARY_PATH or
SHLIB_PATH in different unix'es. Looks like a big mess to me.

Plus *nothing* is written in Guile manuals about all this at all!
Kinda strange for languages poised as "extensions language".

> The author/current-maintainer of guile-gnome is a smart guy and may have
> concluded it's enough for normal install, including debian packages.
>
guile-gnome maintainer did what he thought is right, guile-pg did
different thing and so on. They all are "sensible" in some way but
since there are no single "official way" to handle this situation
different packages are doing different things. This is small problem
now, but if not eliminated it'll grow and make life harder and harder
for distributors (who tend to avoid guile packages even now) and users
(who are confused enough as it is).

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user