On 9/29/05, Ludovic Courtès <[EMAIL PROTECTED]> wrote:
> > In short: do not bother too much with understanding of my default
> > locations choice.
>
> Sure.
>
> So, I'm all in favor of having your patch (or something equivalent)
> applied. I guess you'll need to /kindly/ ask the developers for further
> reviewing and see what needs to be done so that it can actually be
> applied.
>
Where are how should I do this ? I was under impression that this list
is exactly where such changes must be discussed.
> > I did so as well, but surprisingly it's VERY minor issue: since it's
> > determined by GUILE_SITE_DIR and then by guile-config you can change
> > this default quite easily WITHOUT changing third-part extensions code!
>
> This is true since `GUILE_SITE_DIR' is already widely used. In fact,
> the right way to do it would probably be to have:
>
> 1. `%site-dir' (and obviously `GUILE_SITE_DIR') return
> `${datadir}/guile/MAJOR.MINOR/site';
>
> 2. `%load-path' include both `${datadir}/guile/MAJOR.MINOR/site' _and_
> `${datadir}/guile/site' (in this order).
>
...and since GUILE_SITE_DIR is already used by extensions developers
it can be done by Debian, Gentoo or RedHat packagers. No need to lump
different solutions together.
> > Nope. You *can* *not* use them to solve (1). Trivial REAL WORLD
> > sample: university system where you can only install stuff in your own
> > home directory.
>
> Yes you can: have third-party C libraries use Guile's version info.
> IOW, add `-version-info
> $LIBGUILE_INTERFACE_CURRENT:$LIBGUILE_INTERFACE_REVISION:$LIBGUILE_INTERFACE_AGE'
> to your LDFLAGS.
>
How can it solve ANYTHING ? Guile WILL NOT scan anything besides /lib
and /usr/lib (in that order) - even if you'll install it in
/home/canal/my-guile ! Yes, you can play with LTDL_LIBRARY_PATH and
LD_LIBRARY_PATH and do some other hacks - but this is hardly "clean
solution for the problem". And once GUILE can load libraries from
/home/canal/my-guile/lib you can use the same mechanism to solve
multiple installations problem.
> However, this would not permit extension developers to use
> `-version-info' for their own versioning purposes, so it sucks.
>
See above: even with `-version-info' you still must alter libltdl
search path and if you've done this you can use `-version-info' for
some other purpose.
> > 2. Crude yet effective substitute usually enough: just add something
> > like "v2" to name of extension (like glib vs glib2). Not elegant but
> > it works...
>
> Remember: that's what `libguile-readline' already does. You might want
> to re-read your email answer to my suggesting such workarounds. :-)
>
Not really - you can only use libguile-readline with the same version
of guile, so it's solution for the first probem (and it does not
really work as I've shown earlier).
> > In fact I'm not even sure this problem need solution! Think about it:
> > if we'll allow this we should allow two version of, for example (web
> > serialize) module. This means we'll be forced to develop some
> > versioning for scheme modules as well. A lot of work for unknown
> > benefit: in RARE cases where you really need two versions of the same
> > module you can cope with %load-path/%load-libpath tricks.
>
> "Lack of vision" you said earlier, right?
>
Nope. Just simple work/benefits check.
[some rants are skipped]
> Hmm... In fact, that may be much more complicated than it seems since
> `resolve-module' relies on `nested-ref' to find a module, and since
> there can only be one module bound to a given name...
There are a lot of problems to be solved to make versioned modules
usable. While idea in general is not bad it'll require deep rework of
Guile internals, this is not 2-3 hours hack! So this is the case where
you can safely blame lack of manpower.
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
