Re: Release now?

[Greg Troxel <gdt@ir.bbn.com>]

  I'd tend to lean towards having a standard strategy like #:interface
  or maybe #:version for people to use.  They can always ignore it and
  invent their own custom strategies using (use-modules (foo)) if they
  want.  I'm open to being convinced otherwise, though.

This makes sense.  But, I'd lean hard to trying not to change such
interfaces by adding new names and deprecating old procedures over time.
Also, I'm not sure this is causing us pain, and I somewhat lean in the
direction of only favoring complex mechanisms to avoid actual or
near-term expected pain.

  FWIW, as far as I can tell, the only way we can allow compilation for
  multiple versions of guile is if we don't put the libs into /usr/lib
  with the other libraries.  Either that, or we have to put our major
  version number into the library name.

NetBSD's buildlink2 mechanism conses up a special tree to use for
builds, and only puts the libs that are needed there.  I don't know
how this works for locating the right stuff at run-time, but it does
rely heavily on -rpath.

  In fact we wouldn't be able to put *any* libguile.so into /usr/lib,
  otherwise *any* other package's foo-config script that put a
  -L/usr/lib on the gcc command line could cause us to get the wrong
  one, even if the gcc command line also contained the output of an
  invocation of guile-X.Y-config somewhere.

I think this is a general problem of needing the specific -L/-R before
the general locations.

  Another consideration (and perhaps everyone is still aware of) is that
  of -rpath.  There are many who are opposed to it, and without it, you
  don't really have any way to put guile's libs anywhere but /usr/lib or
  similar...

If someone is unwilling to use -rpath and unwilling to use
LD_LIBRARY_PATH, then yes, guile's libs need to be in /usr/lib.  guile
can be built with --prefix=/usr, so this is supported.  This makes it
hard to have two versions unless all libs have versions in the names.
I'm not sure how hard it would be to make /usr/lib/libguile16.so.15
and /usr/lib/libguile14.so.10 instead - and I'm not sure what it would
hurt.  (An example is glib 1.2 and 2.0.)

  Perhaps I'm misunderstanding.  If the soname hasn't changed, then you
  should be fine.  If it has, then you have to recompile...  Also,
  unless we can *prove* that nothing has changed in a way that would
  break backward compatibility, we have to change the soname with each
  major release.

I would advocate bumping the .so # when there is a known incompatible
change, but I see the playing it safe path as reasonable too.

But I wasn't talking about this - I meant compatibility at the
source/build level, not dynamically linking the new .so into an old
binary.  The real pain has happened because one couldn't in general
take a program that built against guile 1.4 and just replace guile
with 1.6 and rebuild it from scratch.  Gnucash 1.6.8 is specified to
only work with 1.4, for example.  If everything could be built against
1.6, even if it did have to be recompiled (e.g. some functions are now
macros that invoke compatibility calls) that would mean everything
needed to be rebuilt, but that's just cpu time, not package pain, at
least in the NetBSD pkgsrc view.  One would just to to
/usr/pkgsrc/lang/guile and type 'make update', and it would
recursively delete and rebuild all that depended on guile.  But
because some programs can't (or are thought not to be able) to build
with new guile, it was necessary to simultaneously support both.

  Also I guess we need to be clear what the C lib sonames mean.  Do they
  also reflect the indirect "API" available from ice-9 via scm_c_eval?
  For example, if we had a function in ice-9 called (get-blarg) that
  returned `(,foo . ,bar), and we change it so that it returns `(,bar
  . ,foo), then do we have to change the libguile version number since
  since C code could access this via scm_c_eval?  Perhaps, perhaps not,
  but I think we should figure this out and make a clear statement in
  the docs.

A very good point.  If we don't take the more strict view, then there
needs to be an interface version accessible via a standard  API.

Or, perhaps we need to say "Don't do that."  Add a new call, and then
deprecate the old one, but don't change documented behavior lightly.

  As far as I can tell, this is always going to be true to some extent,
  though we should do our best to minimize it.  I've seen it happen for
  perl and python regularly, and I'd expect our situation to be worse
  (and it is) because of our unique requirement that users be able to
  link directly to our libraries from C, and that of course leads to
  libs linked to libs linked to guile and the whole "indirect linkage to
  two versions of libguile" problem.
                 
  > So, ensuring that 1.8 is a drop-in replacement for 1.6 would be good,

  If you mean drop-in as in "just requires a recompile of things linked
  against it", then I suspect that's quite possible.  If you mean
  "doesn't even require recompile", then I at least somewhat doubt it.

I meant just requiring a recompile.  But, if the old so is present,
with a different major verison, the old stuff should continue to work.

Thanks for thinking about this - I think it is critical to promoting
guile acceptance and use.

    Greg Troxel <gdt@ir.bbn.com>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel