Re: Managing Guile and extensions versions

[Vorfeed Canal]

On 9/28/05, Ludovic Courtès <address@hidden> wrote:
> Hi,
>
> Vorfeed Canal <address@hidden> writes:
>
> > Of course it must - how else can it load them ? With my patch it knows
> > about few default places and can be instructed about other places in
> > nice shemely way.
>
> Yes, your patch seems to be one possible solution.  However, why not use
> `pkglibdir' (versionizing it) which you mentioned in earlier posts
> instead of this new directory?
>
1. I *am* using pkglibdir - take closer look on patch.
2. It's mostly matter of taste.
  A. Apache and PHP are using one directory
  B. Python and Ruby - two:
    one - for system packages and things installed with package manager
    anouther - for manually installed things, kinda /usr vs /usr/local
  C. Emacs - three:
    one - for bundled files
    one - for universal packages: /usr/share/emacs/site-lisp
    one for specific packages: vs /usr/share/emacs/21.4/site-lisp
  D. Perl - three but for different reasons:
    bundled things will go to /usr/lib/perl5/5.8.6/i686-linux
    package-installed things will go to
/usr/lib/perl5/vendor_perl/5.8.6/i686-linux
    manually-installed - to /usr/lib/perl5/site_perl/5.8.6/i686-linux
3. Guile itself already have %load_path for scheme_extensions and it
looks like this:
  $ guile -c '(display %load-path)'
  (/usr/share/guile/site /usr/share/guile/1.7 /usr/share/guile)
  I think the right idea is to keep list similar in structure.
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.

In short: do not bother too much with understanding of my default
locations choice.

As long as there are some macros defined guile.m4 suitable for putting
in configure.ac I (as extension writer) will be happy. Exact place
where my libraries will be kept not as important: configure will
determine place, Makefile.am will put libraries there, guile will load
them - I'm not really interested in such morbid details, just in the
end result.

Application writer is interested in configurability (I want to add my
own private directory to the list and still keep the ability to load
library from "standard place"), again: what is stored in "standard
places list" is not interesting (as long as SOMETHING stored there).

> The other thing needed, which you also mentioned earlier, is to have a
> versionized site directory.  I've actually always wondered why this one
> was not versioned.
>
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!
And you already can call configure as
GUILE=/usr/bin/guile-1.4 GUILE_CONFIG=/usr/bin/guile-config-1.4
GUILE_TOOLS=/usr/bin/guile_tools ./configure ...

This means only architecture-depenent libraries generated by
third-party modules can not be easily handled...

> >> This is true I guess, because `dynamic-link' doesn't allow to specify
> >> version info.  _This_ is an issue and maybe this procedure could be
> >> fixed by allowing the user to pass Libtool-like version information.
> >
> > This is one solution. And IMO not the best solution.
>
> That's a solution to one of the two problems, the two problems being:
>
> 1.  Separating C libraries that are written for different versions of
>     Guile, allowing to have versions of the same extension written for
>     different Guile versions to coexist;
>
> 2.  Allowing to have different versions of a given extension for a same
>     version of Guile.
>
> Your patch addresses (1).  This `dynamic-link' thing could be used to
> address (2).  It could be used to address (1) instead, but certainly not
> both of them.

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.

> Anyway, we'd first need `libltdl' to allow for such  things.
> I started to ask the Libtool people about this:
> http://lists.gnu.org/archive/html/libtool/2005-09/msg00118.html .
>
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).
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...

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.