Re: Multiple version
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
Guile-SNMP 0.2.3
Hi All, I've just released guile-snmp-0.2.3 on github. I've included the NEWS below and in addition to that there's also SNMPv3 support, support for async calls (which in turns means you can use it as a trap reciever). expanded use of goops generics for access to wrapped types, and support for snmp getbuilk. There's also an included spec file that now only gets 1 warning on rpmlint, though I've not tested the resulting packages yet. I'm going to work on a bit of syntactic sugar for creating agents, and direct use of SMI textual conventions (octet-str display hints are working but aren't used by default as it'll break the API). Changes in guile-snmp-0.2.3 (since guile-snmp-0.2.2) * MIB browsing: You can now use goops' describe function to get information about a MIB module, or an oid e.g.: (use-mibs BRIDGE-MIB) (describe BRIDGE-MIB) (describe dot1dStpRootPort) * (snmp display-hint) provides apply-octet-str-display-hint to value-bytes to a string using the relevant display hint. This will be automated in future * Basic agent support: The net-snmp agent handler infrastructure for scalars and tables are now wrapped. This work as stand alone and AgentX * Agents sysORTable registration via (un)register-sysor-table * Some fixes to ASN-TYPE handling around signedness * Fixes to setting/serving of ASN-OBJECT-ID varbinds * Support ASN-FLOAT and ASN-DOUBLE * Some more OID related routines: oid? predicate oid-length retrieves length of an oid (/ oid1 oid2) is oid2 a prefix of oid1 * Various bug fixes for automated oid resolution -- Tristan Colgate-McFarlane "You can get all your daily vitamins from 52 pints of guiness, and a glass of milk"
Re: Multiple version
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? pgp4Eceero7cj.pgp Description: PGP signature
Re: Multiple version
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. pgpR2Jsvnzj3t.pgp Description: PGP signature
