Multiple version

Multiple version

[Tom Willemsen]

Hey everyone,

I was wondering if it's possible to have guile 1.8 and guile 2.0
installed on the same system? I remember reading in the documentation
that it is, but I haven't been able to pull it off yet, except by using
different --prefix values for each.

The problem is that the distro I'm using (Archlinux) has guile 1.8 in
its repository and certain applications (like xbindkeys and freetalk)
still depend on it being this version. There are also at least two
packages in the Arch User Repository that provide guile 2.0, but these
both conflict with 1.8, so I can't yet install both.

I've tried a couple of times: I've used the --program-suffix argument to
make all binaries end with 2 (guile2, guild2, etc.), kind of like Python
does, but this doesn't help with the symlink of guile-tools (for
backwards compatibility). The --infodir argument is useful for keeping
the documentation seperate. That still leaves guile.m4.

I don't know enough about the autotools to know what to do with
guile.m4. Does automake/autoconf expect the file name to match
something, or does it only look at the definitions inside, in which case
it could simply be moved.

I've been looking at it for a while now and I'd really just like to know
if it's possibly to have both on the system and be able to use
everything in the 'regular' way.

I hope my question is clear. Thanks in advance!

Cheers,
Tom

Re: Multiple version

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]


  I was wondering if it's possible to have guile 1.8 and guile 2.0
  installed on the same system? I remember reading in the documentation
  that it is, but I haven't been able to pull it off yet, except by using
  different --prefix values for each.

pkgsrc (a packaging system originally for NetBSD, but also supports
other BSDs, Linux, *Solaris, and others) doesn't have guile 2 yet (my
fault :-) but has 1.6 and 1.8.  1.8 is installed normally
(--prefix=/usr/pkg, named guile) and guile1.6 is installed
--prefix=/usr/pkg/guile/1.6.   So that's a data point about others'
approach to your problem.

  I don't know enough about the autotools to know what to do with
  guile.m4. Does automake/autoconf expect the file name to match
  something, or does it only look at the definitions inside, in which case
  it could simply be moved.

You only need that to run autoconf on programs that depend on guile, and
either should be ok.  So you could patch it out of the 2.0 build.
But having a separate prefix seems easiest.

What's wrong (or actually problematic) about using /usr/guile2 as the
prefix for guile 2.0, and putting it in your path and/or passing that
for building other things?

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: Multiple version

[Tom Willemsen]

Hey Greg,

On Tue 03 Apr 2012 02:32:39 AM CEST, Greg Troxel wrote:

 >
 >   I was wondering if it's possible to have guile 1.8 and guile 2.0
 >   installed on the same system? I remember reading in the documentation
 >   that it is, but I haven't been able to pull it off yet, except by using
 >   different --prefix values for each.
 >
 > pkgsrc (a packaging system originally for NetBSD, but also supports
 > other BSDs, Linux, *Solaris, and others) doesn't have guile 2 yet (my
 > fault :-) but has 1.6 and 1.8.  1.8 is installed normally
 > (--prefix=/usr/pkg, named guile) and guile1.6 is installed
 > --prefix=/usr/pkg/guile/1.6.   So that's a data point about others'
 > approach to your problem.

Yeah I got this far with guile 2.0 as well.

 >   I don't know enough about the autotools to know what to do with
 >   guile.m4. Does automake/autoconf expect the file name to match
 >   something, or does it only look at the definitions inside, in which case
 >   it could simply be moved.
 >
 > You only need that to run autoconf on programs that depend on guile, and
 > either should be ok.  So you could patch it out of the 2.0 build.
 > But having a separate prefix seems easiest.

I understand, I know just enough about autoconf to know that }:)

But if I write something that depends on guile, would I have to change
anything in my scripts to use guile 2.0 if I've installed the file as,
for example, guile2.m4?

 > What's wrong (or actually problematic) about using /usr/guile2 as the
 > prefix for guile 2.0, and putting it in your path and/or passing that
 > for building other things?

There's nothing really wrong, I just think it's a little
unnecessary. Since guile seems to be able to live next to other versions
of itself for about 90%. All the library files and script files are
already in a special directory, only some of the other files
(info,m4,guile-tools) seem to conflict.

Anyway, it's not really a problem, it's pretty much just lazyness and
curiosity. I would like to use software for both versions with minimal
patching and I would like to be able to write software for guile 2
without using all kinds of configuration specific to my case.

I should probably just try it with a renamed guile.m4, I was actually
hoping for some recommendations or warnings or stories about how other
people handle it, I don't want to do something that goes completely
against all recommendations.

Thanks for your answer!

Cheers,
Tom

Re: Multiple version

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]


I think that aclocal looks for files that define needed macros, so you'd
still get a conflict even if the file is renamed.

  But if I write something that depends on guile, would I have to change
  anything in my scripts to use guile 2.0 if I've installed the file as,
  for example, guile2.m4?

Not if 
  a) your code actually builds with guile 2, and
  b) the aclocal m4 code with 1.8 finds guile2 ok

now that guile does pkg-config, i would think that's preferable, but if
a package installs scheme files into share/guile/site then it may not be
adequate.

Your programs that use guile should just be able to do
--with-guile=/usr/guile2 or some such.

If you want to fix this, I think it only makes sense to get patches into
guile to make program-suffix work 100%, and otherwise you risk being in
a wet-noodle-pushing exercise.


[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]