[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Managing Guile and extensions versions
From: |
Ludovic Courtès |
Subject: |
Re: Managing Guile and extensions versions |
Date: |
Thu, 29 Sep 2005 17:34:37 +0200 |
User-agent: |
Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) |
Hi Vorfeed,
Vorfeed Canal <address@hidden> writes:
> 4. Actual contents of default directory list is not important. Only
> two requirements:
> A. It must not be empty - this way there are place to put default
> libraries like readline.
> B. It must be modifyable at runtime - this way complex program (like
> Gnumeric or
> Gnucash) can keep it's private libraries private and not pollute
> default directory.
Right.
> 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.
> 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).
> 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.
However, this would not permit extension developers to use
`-version-info' for their own versioning purposes, so it sucks.
> Yes, it'd be quite nice to allow both (1) and (2). But!
> 1. It'll require major redesign or libtool (actual shared library is
> versioned, but .la file is not).
I don't think so but that discussion belongs to `libtool@'.
> 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. :-)
> 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?
I believe Scheme module versioning would be beneficial, although I have
lived without it so far. Anyway, a quite straightforward solution (at
first sight, at least) would be something like:
(define-module (my-module)
#:version/current 2
#:version/age 1
#:version/revision 4)
And:
(use-modules ((my-module) #:interface 1))
This would look for `my-module.scm' in the directories of `%load-path'
and only import bindings from the first one (for instance) that
implements version 1 of the interface, in pure Libtool style. And
AFAICS, this wouldn't introduce any compatibility issue: both versioned
and unversioned modules and module users could peacefully coexist.
That may add some overhead in the rare case where a significant number
of different versions of a module are available, since Guile needs to
load each module before knowing whether it matches the constraint.
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...
Thanks,
Ludovic.
- Re: PHP to GUILE, (continued)
Exceptions, Ludovic Courtès, 2005/09/26
- Re: Exceptions, Vorfeed Canal, 2005/09/26
- Re: Exceptions, Ludovic Courtès, 2005/09/27
- Re: Exceptions, Vorfeed Canal, 2005/09/27
- Re: Exceptions, Ludovic Courtès, 2005/09/27
- Re: Exceptions, Vorfeed Canal, 2005/09/27
- Managing Guile and extensions versions, Ludovic Courtès, 2005/09/28
- Re: Managing Guile and extensions versions, Vorfeed Canal, 2005/09/28
- Re: Managing Guile and extensions versions,
Ludovic Courtès <=
- Re: Managing Guile and extensions versions, Vorfeed Canal, 2005/09/29
- Re: Managing Guile and extensions versions, Neil Jerram, 2005/09/30
Re: Managing Guile and extensions versions, Kevin Ryde, 2005/09/29
Re: Managing Guile and extensions versions, Ludovic Courtès, 2005/09/30
Re: PHP to GUILE, Neil Jerram, 2005/09/26