Hi Vorfeed, Vorfeed Canal <[EMAIL PROTECTED]> 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. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user