* Release now? @ 2003-02-24 12:37 Mikael Djurfeldt 2003-02-24 13:08 ` Dale P. Smith ` (3 more replies) 0 siblings, 4 replies; 34+ messages in thread From: Mikael Djurfeldt @ 2003-02-24 12:37 UTC (permalink / raw) Cc: djurfeldt When Rob has added the GMP support there's only the signal handling left of the major changes intended for the 1.8 release, right? I think it would be a good idea to aim for release of 1.8 after these two components have been added. This since people have asked for shorter intervals between releases. What do you say? M _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-24 12:37 Release now? Mikael Djurfeldt @ 2003-02-24 13:08 ` Dale P. Smith 2003-02-24 13:21 ` Mikael Djurfeldt 2003-02-24 13:32 ` Greg Troxel ` (2 subsequent siblings) 3 siblings, 1 reply; 34+ messages in thread From: Dale P. Smith @ 2003-02-24 13:08 UTC (permalink / raw) On Mon, 24 Feb 2003 13:37:33 +0100 Mikael Djurfeldt <mdj@kvast.blakulla.net> wrote: > When Rob has added the GMP support there's only the signal handling > left of the major changes intended for the 1.8 release, right? > > I think it would be a good idea to aim for release of 1.8 after these > two components have been added. This since people have asked for > shorter intervals between releases. > > What do you say? Well! 1.6.3 isn't in Debian unstable yet. Doesn't 1.8 remove the gh_* interface? Shouldn't there be some time for extension and application writers to move to 1.6 before 1.8? -Dale -- Dale P. Smith Senior Systems Consultant, | Treasurer, Altus Technologies Corporation | Cleveland Linux Users Group dsmith@altustech.com | http://cleveland.lug.net 440-746-9000 x239 | _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-24 13:08 ` Dale P. Smith @ 2003-02-24 13:21 ` Mikael Djurfeldt 0 siblings, 0 replies; 34+ messages in thread From: Mikael Djurfeldt @ 2003-02-24 13:21 UTC (permalink / raw) Cc: djurfeldt "Dale P. Smith" <dsmith@altustech.com> writes: > Doesn't 1.8 remove the gh_* interface? I propose that it doesn't do more than what has been achieved after the GMP and signal handling has been added. The major additions will then be: GMP, POSIX threads and resizing hash tables. > Shouldn't there be some time for extension and application writers > to move to 1.6 before 1.8? If we release 1.8 now, the non-deprecated API will have had only cosmetic changes, so it wouldn't be a significant extra burden for those who have adapted to the non-deprecated API of 1.6. Besides, the signal handling will likely take some time to complete. If we then initiate the release process, chances are that the release won't happen until summer, so 1.6 will have at least half a year of "life". So, "now" means "in half a year". But if we don't start to plan for it now, it will be longer... M _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-24 12:37 Release now? Mikael Djurfeldt 2003-02-24 13:08 ` Dale P. Smith @ 2003-02-24 13:32 ` Greg Troxel 2003-02-25 13:34 ` Marius Vollmer 2003-02-24 18:35 ` Rob Browning 2003-02-25 13:20 ` Marius Vollmer 3 siblings, 1 reply; 34+ messages in thread From: Greg Troxel @ 2003-02-24 13:32 UTC (permalink / raw) Cc: Marius Vollmer I'm all for shorter intervals between releases, but it would be good to make sure that packages expecting 1.6 can work with 1.8 (modulo insisting on a specific version when it isn't necessary, which is easy to patch). It sounds like this is indeed the case. The 1.4->1.6 transition has been awkward - NetBSD pkgsrc now has a 'guile14' pkg installed in /usr/pkg/guile/1.4/ as well guile (1.6) installed in /usr/pkg. Unless one can say there is absolutely no good reason for a program to need an older version, it has to be doable for a package system to support both. And supporting both means having both fully installed so you can link against either - not just run old binaries. NetBSD seems to have achieved this with the dual-prefix approach and the buildlink2 scheme (which tightly controls a pkg's build environment). IMHO, the dual-prefix approach points out that depending on LD_LIBRARY_PATH is potentially troublesome. This works out ok with -R on NetBSD: fnord gdt 35 ~ > ldd /usr/pkg/guile/1.4/bin/guile /usr/pkg/guile/1.4/bin/guile: -lltdl.3 => /usr/pkg/lib/libltdl.so.3 -lm.0 => /usr/lib/libm387.so.0 -lm.0 => /usr/lib/libm.so.0 -lguile.10 => /usr/pkg/guile/1.4/lib/libguile.so.10 -lc.12 => /usr/lib/libc.so.12 fnord gdt 36 ~ > ldd /usr/pkg/bin/guile /usr/pkg/bin/guile: -lcrypt.0 => /usr/lib/libcrypt.so.0 -lm.0 => /usr/lib/libm387.so.0 -lm.0 => /usr/lib/libm.so.0 -lguile-ltdl.1 => /usr/pkg/lib/libguile-ltdl.so.1 -lguile.15 => /usr/pkg/lib/libguile.so.15 -lc.12 => /usr/lib/libc.so.12 And, given that the libguilereadline lib has different names, readline works on both guile versions. So, I consider this a success story - thanks to ebayasi, wiz and mycroft for working on NetBSD guile pkgsrc. All that said, I'm hoping that NetBSD and others can just update the 1.6 version of guile to 1.8, and not have to have 1.6 installed under /usr/pkg/guile/1.6. It's really cool that guile is starting to be included in more pkgsrc builds (e.g. gnumeric), where it had previously been avoided! Greg Troxel <gdt@ir.bbn.com> _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-24 13:32 ` Greg Troxel @ 2003-02-25 13:34 ` Marius Vollmer 2003-02-25 16:08 ` Greg Troxel 2003-02-25 16:28 ` Andreas Rottmann 0 siblings, 2 replies; 34+ messages in thread From: Marius Vollmer @ 2003-02-25 13:34 UTC (permalink / raw) Cc: Mikael Djurfeldt Greg Troxel <gdt@ir.bbn.com> writes: > I'm all for shorter intervals between releases, but it would be good > to make sure that packages expecting 1.6 can work with 1.8 (modulo > insisting on a specific version when it isn't necessary, which is easy > to patch). Yes, we definitely need to be able to have two versions of Guile installed with the same prefix and have them be usable for running programs. However, I don't think we need to make special arrangements for being able to compile against two versions of Guile at the same time. Having to use different prefices for the two versions seems acceptable to me. Would pkg-config address this issue? I.e. could one say `guile-config --use-version 1.6 link` (or something similar) with the effect that the right '-L' and '-R' options are spit out? However, a more serious problem exists for external modules of Scheme code that want to use a specific version of Guile. For this, I think we should add versions to our module system. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-25 13:34 ` Marius Vollmer @ 2003-02-25 16:08 ` Greg Troxel 2003-02-25 18:38 ` Rob Browning 2003-02-25 16:28 ` Andreas Rottmann 1 sibling, 1 reply; 34+ messages in thread From: Greg Troxel @ 2003-02-25 16:08 UTC (permalink / raw) Cc: Mikael Djurfeldt For NetBSD pkgsrc, a normal case is for people to build everything from source. So it is necessary to have multiple versions installed such that someone could compile against either, since some programs (e.g Gnucash 1.6.8) require the old version of guile. NetBSD pkgsrc has solved this by putting one in a special prefix. Would pkg-config address this issue? I.e. could one say `guile-config --use-version 1.6 link` (or something similar) with the effect that the right '-L' and '-R' options are spit out? pkg-config might well be nice, and arguably guile should provide a pkg-config file, even if we continue to have guile-config. I am not clear whether pkg-config is a 'gnome thing', and whether it is ok to require people who want to link against gruile to install pkg-config. I find it to be a solution to a general problem and not huge (gzipped binary package < 50 KB on NetBSD/i386). But, running 'pkg-config --use-version 1.6' should be no different than guile16-config, except that it's easier to write configure.in fragments. It does mean we get to sidestep the issue about which guile-config is 'primary' and which has a version number. But I'm not sure that's a huge issue - the latest can be primary and the others have the number. However, a more serious problem exists for external modules of Scheme code that want to use a specific version of Guile. For this, I think we should add versions to our module system. The NetBSD pkgsrc approach means that when one compiles guile-gtk, for instance, one could put the 1.4-linked version in /usr/pkg/guile/1.4 and the 1.6 version in /usr/pkg. Do you really mean pure Scheme code, or stuff with dynlibs? I would think that pure Scheme code could feature-test and cope - is this really an issue? (I have not heard of gnucash having problems with this.) But, this all points out the really serious extended consequences of not maintaining _compile-time_ backwards compatibility. I'm not (personally) at all worried about running old binaries with newer guile libraries. The issue is whether programs that compile against guile can just work when the system's base guile version is upgraded. We've seen a lot of pain (and non-upgrading of guile in major distributions) recently. So, ensuring that 1.8 is a drop-in replacement for 1.6 would be good, and there probably needs to be some schedule for removing deprecated features. Something like 1-2 years after 75% of some set of distributions have 1.6 in their base pkg/ports/rpm/deb system, perhaps with some survey of the guile-using packages. Greg Troxel <gdt@ir.bbn.com> _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-25 16:08 ` Greg Troxel @ 2003-02-25 18:38 ` Rob Browning 2003-02-26 1:51 ` Greg Troxel 0 siblings, 1 reply; 34+ messages in thread From: Rob Browning @ 2003-02-25 18:38 UTC (permalink / raw) Cc: Marius Vollmer Greg Troxel <gdt@ir.bbn.com> writes: > But, running 'pkg-config --use-version 1.6' should be no different > than guile16-config, except that it's easier to write configure.in > fragments. It does mean we get to sidestep the issue about which > guile-config is 'primary' and which has a version number. But I'm > not sure that's a huge issue - the latest can be primary and the > others have the number. Or you can do something like Debian's update-alternatives -- have a priority system, but allow for the local maintainer to override... 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. 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. 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... Hmm, now that I think about it, I wonder if systems could handle just having the .so links off in a subdir, i.e. put libguile.so in /usr/lib/guile/VERSION, but put the actual libguile libs in /usr/lib. This might avoid the need for an -rpath, LD_LIBRARY_PATH, or any changes to ld.so.conf, but still allow specifying a particular guile with -L/usr/lib/guile/VERSION. Hmm... Thoughts? > The NetBSD pkgsrc approach means that when one compiles guile-gtk, > for instance, one could put the 1.4-linked version in > /usr/pkg/guile/1.4 and the 1.6 version in /usr/pkg. Do you really > mean pure Scheme code, or stuff with dynlibs? I would think that > pure Scheme code could feature-test and cope - is this really an > issue? Personally I feel like it is. To me it seems like just as much an issue as it is for binary shared libraries. A module presents an interface, and that interface may change over time. So the client should have some way to ask for a particular "version" of that interface i.e. (use-modules (postgresql-fancy #:interface 3)). Of course, others may differ and feel like we should just leave this up to the author and client to come up with their own scheme, i.e. checking version number, defined?, etc. Though note that I'm not sure we've settled the future of some of the features like defined?. 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. > But, this all points out the really serious extended consequences of > not maintaining _compile-time_ backwards compatibility. I'm not > (personally) at all worried about running old binaries with newer > guile libraries. The issue is whether programs that compile against > guile can just work when the system's base guile version is > upgraded. 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. 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. > We've seen a lot of pain (and non-upgrading of guile in major > distributions) recently. 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. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-25 18:38 ` Rob Browning @ 2003-02-26 1:51 ` Greg Troxel 2003-02-26 2:27 ` Rob Browning 0 siblings, 1 reply; 34+ messages in thread From: Greg Troxel @ 2003-02-26 1:51 UTC (permalink / raw) Cc: Marius Vollmer 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-26 1:51 ` Greg Troxel @ 2003-02-26 2:27 ` Rob Browning 2003-02-27 14:25 ` Greg Troxel 0 siblings, 1 reply; 34+ messages in thread From: Rob Browning @ 2003-02-26 2:27 UTC (permalink / raw) Cc: Marius Vollmer Greg Troxel <gdt@ir.bbn.com> writes: > 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. I think I tend to look at it as setting up infrastructure now that encourages people to do things that may save anguish later, but I can also see your point. Though I did have the semi-amusing idea of trying to make guile nearly all modules (which I think I've mentioned before), i.e. #!/usr/bin/guile-strap -s \ !# (use-modules (ice-9 core #:interface 6)) ... I think it's probably simpler and more obviously useful to just standardize our naming convention. I'm inclined to change the unstable tree to install guile as guile-X.Y from now on, along with all the other tools, and have an easily bypassable inst-hook (or similar) that sets up the default links: cd ${bindir} && ln -sf guile-X.Y guile I might also try to make another install target that didn't set up the links, perhaps "make install-no-convenience-links" or whatever. This would allow people to reliably start writing #!/usr/bin/guile-1.6 scripts, or maybe more portably #!/bin/sh exec guile-1.6 "$@" > 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.) What do you think about my other suggestion? i.e. - put libguile.so.*, etc. in /usr/lib (i.e. ${libdir}) - put the libguile.so development symlinks (i.e. the ones -l uses) in /usr/lib/guile/VERSION - put the headers in /usr/include/guile/VERSION - require the use of guile-config and arrange for guile-config to spit out -I/usr/include/guile/VERSION and -L/usr/lib/guile/VERSION when appropriate So far this seems to me like it might solve the "allow multiple development versions to be installed" problem without requiring -rpath, LD_LIBRARY_PATH, or ld.so.conf modifications, but I haven't been thinking about it for long yet. If this *would* work, I can implement it in CVS, and adjust Debian accordingly... Basically gcc -lguile would find the libguile.so in /usr/lib/guile/VERSION/ via the -L argument from guile-X.Y-config, and would use that to embed the right SONAME into the app or lib being built. Then at runtime, the linker would find the newest suitable version, say libguile.so.12.0.1 in /usr/lib/. > 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. I won't argue that the 1.4 -> 1.6 transition was possibly somewhat jarring. While I still feel like many of those changes were worthwhile and will serve us well going forward, I think that we're likely to do that less often going forward. As Marius has mentioned, we'll be restoring a number of things in CVS that had already been removed in preparation for 1.8. > Thanks for thinking about this - I think it is critical to promoting > guile acceptance and use. You and I both :> Though guile's particular objectives do provide some fairly "challenging" constraints on the possible solutions. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-26 2:27 ` Rob Browning @ 2003-02-27 14:25 ` Greg Troxel 2003-02-27 15:21 ` pkg-config support for guile Greg Troxel 2003-02-27 16:54 ` Release now? Rob Browning 0 siblings, 2 replies; 34+ messages in thread From: Greg Troxel @ 2003-02-27 14:25 UTC (permalink / raw) Cc: guile-devel What do you think about my other suggestion? i.e. - put libguile.so.*, etc. in /usr/lib (i.e. ${libdir}) - put the libguile.so development symlinks (i.e. the ones -l uses) in /usr/lib/guile/VERSION - put the headers in /usr/include/guile/VERSION - require the use of guile-config and arrange for guile-config to spit out -I/usr/include/guile/VERSION and -L/usr/lib/guile/VERSION when appropriate I suppose /usr/share/guile/VERSION already exists, and /usr/bin/guile (and guile-config) can be named with versions as well. It strikes me as inelegant to link against a library in one place and then expect ld.so to find it someplace else. I think your plan is workable, but in my view the 'put the other version in a different prefix' plan feels cleaner. But, it requires rpath or DT_RPATH, which seems to be ok in most places except debian. (It is certainly heavily used in NetBSD, which puts third party stuff in /usr/pkg and does not have /usr/pkg/lib in the default search path.) At this point, for NetBSD I'm happy with NetBSD's current solution. I would be perfectly content for your plan to be a ./configure-time option, as it seems to be among the best suggestions to date for a no-rpath environment. I suppose if guile-config/pkg-config spits out the right -I and -L paths then this would be ok for other systems. But having a library compile-linked from one place and run-linked from another seems to be asking for trouble, and I would prefer not to see that complexity and associated unintended consequences imposed on everyone because Debian chooses not to use -rpath. (I realize libtool does this for running uninstalled code, but I think that's different.) All that said, I have to ask myself: what's wrong with putting the guile version number in the soname and all other files, glib-style? This makes names bigger, but seems less likely to create hard-to-find bugs. This could also be a ./configure-time option, perhaps used only when installing a secondary version. Or, on systems that say dependency libs have to be updateable without reinstalling dependent programs, this should perhaps be used all the time. In December you wrote to debian-devel: One solution might be to just require all guile add-on libs to be placed in /usr/lib/guile/X.Y and then require the use of -rpath or similar, but I suspect that's a non-starter. Another might be to make it guile policy to encode the name of the guile version into the lib name, i.e. libguile1.6-gwrap-glib, but that's pretty ugly and it's not very scalable. I think it is important to keep separate notions of scalability imposed by such a naming scheme and the scalability of the underlying reality. Here, the reality is messy, and the naming scheme means that various combinations can coexist peacefully. It enables having 12 versions at once, but that is the underlying reality, unless some are prohibited. Of course, not having a mechanism has the effect of prohibiting this. Why wouldn't such a rationale also justify libguile1.6-gwrap-glib1.2-crypt1-c6,so? It justifies only libguile1.6-gwrap-glib1.2. The key point that I've been trying to get across (which our discussion has clarified in my mind) is that there are two separate kinds of version changes. One is the traditional shlib major version bump. But generally, that merely means programs must recompile, and make an occasional small change. The other kind is that interfaces have changed so significantly that it isn't reasonable to tell people "Just recompile and fix your program. From now on only the new version is available and if you can't cope you are just going to lose." The "just cope" is what happens when libc has a major version change. The work to cope is not too bad, and it isn't viewed as reasonable to provide a way around it. I'm hoping that guile 1.6->1.8 will be like this. Other changes, like glib 1.2 to 2.0, are so far reaching that the maintainers feel the need to support having them both installed. Part of the reality is that the more important a library is, the more effort the library can impose on users with changes. With guile, we want people to use guile more than they feel the need, so the amount of pain we can impose is small. Greg Troxel <gdt@ir.bbn.com> _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* pkg-config support for guile 2003-02-27 14:25 ` Greg Troxel @ 2003-02-27 15:21 ` Greg Troxel 2003-03-22 23:31 ` Marius Vollmer 2003-02-27 16:54 ` Release now? Rob Browning 1 sibling, 1 reply; 34+ messages in thread From: Greg Troxel @ 2003-02-27 15:21 UTC (permalink / raw) Cc: guile-devel [-- Attachment #1: Type: text/plain, Size: 649 bytes --] Here is a patch against guile-1.6.1 to add pkg-config support. This is noninvasive - it doesn't require pkg-config to be installed to build guile, or even to run the autogen.sh. pkg-config haters, should there be any, will just see a small turd in $(prefix)/lib/pkgconfig/guile.pc. The file won't be useful without pkg-config installed, of course, but this gives users a choice of configuration means. I have not tested building programs using pkgconfig instead of guile-config, but they give almost the same output (pkgconfig moves all the -L to the front, and allows one to ask for -L separate from -l). Greg Troxel <gdt@ir.bbn.com> [-- Attachment #2: pkgconfig support for guile 1.6 --] [-- Type: text/plain, Size: 1631 bytes --] Index: Makefile.am =================================================================== RCS file: /QUIST-CVS/guile/Makefile.am,v retrieving revision 1.1.1.3 diff -u -r1.1.1.3 Makefile.am --- Makefile.am 2002/12/07 22:41:28 1.1.1.3 +++ Makefile.am 2003/02/27 14:36:25 @@ -29,7 +29,7 @@ include_HEADERS = libguile.h EXTRA_DIST = HACKING GUILE-VERSION ANON-CVS SNAPSHOTS \ - $(ACLOCAL) BUGS README-PACKAGING + $(ACLOCAL) BUGS README-PACKAGING guile.pc.in TESTS = check-guile @@ -37,5 +37,8 @@ # The rule will cd to $(top_srcdir). ACLOCAL = ./guile-aclocal.sh + +pkgconfigdir = $(libdir)/pkgconfig +pkgconfig_DATA = guile.pc # Makefile.am ends here Index: configure.in =================================================================== RCS file: /QUIST-CVS/guile/configure.in,v retrieving revision 1.1.1.3 diff -u -r1.1.1.3 configure.in --- configure.in 2002/12/08 01:48:52 1.1.1.3 +++ configure.in 2003/02/27 14:37:37 @@ -745,6 +745,8 @@ AC_CONFIG_FILES([libguile/guile-snarf-docs], [chmod +x libguile/guile-snarf-docs]) +AC_CONFIG_FILES([guile.pc]) + AC_OUTPUT dnl Local Variables: Index: guile.pc.in =================================================================== RCS file: guile.pc.in diff -N guile.pc.in --- /dev/null Thu Feb 27 03:35:16 2003 +++ guile.pc.in Thu Feb 27 09:37:37 2003 @@ -0,0 +1,12 @@ +# pkgconfig file for guile +prefix=@prefix@ +exec_prefix=@exec_prefix@ +libdir=@libdir@ +includedir=@includedir@ + +Name: guile +Version: 1.6 +Description: guile extension language +Requires: +Libs: -L${libdir} -lguile -lguile-ltdl @LDFLAGS@ @LIBS@ +Cflags: -I${includedir} [-- Attachment #3: Type: text/plain, Size: 142 bytes --] _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pkg-config support for guile 2003-02-27 15:21 ` pkg-config support for guile Greg Troxel @ 2003-03-22 23:31 ` Marius Vollmer 2003-04-23 21:22 ` Greg Troxel 0 siblings, 1 reply; 34+ messages in thread From: Marius Vollmer @ 2003-03-22 23:31 UTC (permalink / raw) Cc: Rob Browning Greg Troxel <gdt@ir.bbn.com> writes: > Here is a patch against guile-1.6.1 to add pkg-config support. Thanks. I'm not sure what to do about this, tho. I don't think we should offer two ways to get configuration information about Guile. When pkgconfig is better than our current method, we should use it exclusively. When not, we should keep our current stuff. (When I say "we should use pkgconfig exclusively", I mean we should use it to re-implement guile-config in a compatible way. We should definitely continue to offer the guile-config interface.) > The file won't be useful without pkg-config installed, of course, > but this gives users a choice of configuration means. Why would they need this choice? [genuine question(tm)] -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pkg-config support for guile 2003-03-22 23:31 ` Marius Vollmer @ 2003-04-23 21:22 ` Greg Troxel 2003-05-16 23:21 ` Marius Vollmer 0 siblings, 1 reply; 34+ messages in thread From: Greg Troxel @ 2003-04-23 21:22 UTC (permalink / raw) Cc: Rob Browning [I sent a patch to add pkg-config support.] I don't think we should offer two ways to get configuration information about Guile. When pkgconfig is better than our current method, we should use it exclusively. When not, we should keep our current stuff. pkgconfig is better in that programs that use guile will not have to include a guile-specific m4 fragment into configure - there is a standard pkgconfig m4 fragment that suffices to link all programs that use pkgconfig for config info. But programs needing GUILE_MODULE_FOO will still need the guile m4. This is really a separate problem from guile-config - using guile as a scripting language rather than a libary, so not trying to use pkgconfig here seems fine. I don't understand why you think there should not be two ways. Users can use whichever way they like better, and this makes guile more friendly. Over time, I expect pkg-config to be more prevalent. The pkg-config support is very small, and most of the contents are substituted via configure. So having two ways is a reasonable transition strategy. (When I say "we should use pkgconfig exclusively", I mean we should use it to re-implement guile-config in a compatible way. We should definitely continue to offer the guile-config interface.) Sure, the old interface should be retained. But the real win comes from people being able to just write a simple line to include the library that is similar to how many other libraries are included. I have a line in some of my own (unpublished so far) sources that reads: PKG_CHECK_MODULES(FOO, libfoo, AC_DEFINE(HAVE_LIBFOO), true) The final 'true' prevents an error if the package is not found. > The file won't be useful without pkg-config installed, of course, > but this gives users a choice of configuration means. Why would they need this choice? [genuine question(tm)] Well, it seems the world is heading to a standardized method of representing how to link with libraries (and handling recursive dependencies, so linking with gtk gets you glib without explicitly asking for it). I view this as an abstraction of using libraries with autoconf, and it's really only better because it implements a well-defined interface instead of the ad-hoc sort-of-like-other-packages homegrown one in guile. The only downside is that the pkgconfig way requires that pkgconfig be installed on systems where one links with pkgconfigized libraries. pkgconfig is installed on most systems, since both the gnome and kde worlds need it. Greg Troxel <gdt@ir.bbn.com> _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pkg-config support for guile 2003-04-23 21:22 ` Greg Troxel @ 2003-05-16 23:21 ` Marius Vollmer 0 siblings, 0 replies; 34+ messages in thread From: Marius Vollmer @ 2003-05-16 23:21 UTC (permalink / raw) Cc: Rob Browning Greg Troxel <gdt@ir.bbn.com> writes: > [I sent a patch to add pkg-config support.] > > I don't think we should offer two ways to get configuration > information about Guile. When pkgconfig is better than our current > method, we should use it exclusively. When not, we should keep our > current stuff. > > pkgconfig is better in that programs that use guile will not have to > include a guile-specific m4 fragment into configure - there is a > standard pkgconfig m4 fragment that suffices to link all programs that > use pkgconfig for config info. > > But programs needing GUILE_MODULE_FOO will still need the guile m4. > This is really a separate problem from guile-config - using guile as a > scripting language rather than a libary, so not trying to use > pkgconfig here seems fine. > > I don't understand why you think there should not be two ways. Users > can use whichever way they like better, and this makes guile more > friendly. Yes, I agree. I wasn't precise enough when I said "there should not be two ways to get confiuration information about Guile". I was really only thinking about how we maintain the code for exporting this configuration information, not about how users will access it. That is, my only worry is that when add support for pkg-config, and continue to offer guile-config (which we should), then there is the risk that the two mechanism diverge over time when they are separately implemented. There should only be a single point in the code where the exported configuration information is defined and both user interfaces (pkg-config and guile-config) should draw from that source. For example, the "Libs:" line in guile.pc needs to stay in sync with the corresponding stuff in guile-config. This should happen automatically. Also, we will need documentation for how to use pkg-config with Guile, maybe with a pointer to generic pkg-config. That's what keeps me from applying the patch right away (and I hope others agree that it is not unreasonable). -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-27 14:25 ` Greg Troxel 2003-02-27 15:21 ` pkg-config support for guile Greg Troxel @ 2003-02-27 16:54 ` Rob Browning 2003-02-27 18:07 ` Greg Troxel 2003-02-27 19:06 ` Rob Browning 1 sibling, 2 replies; 34+ messages in thread From: Rob Browning @ 2003-02-27 16:54 UTC (permalink / raw) Cc: guile-devel Greg Troxel <gdt@ir.bbn.com> writes: > But having a library compile-linked from one place and run-linked from > another seems to be asking for trouble, and I would prefer not to see > that complexity and associated unintended consequences imposed on > everyone because Debian chooses not to use -rpath. (I realize libtool > does this for running uninstalled code, but I think that's different.) I'm somewhat tempted to try it in HEAD, and then get as many people as possible to attempt a build/install. If it works on a bunch of platforms, and if we can't think of any reason why it shouldn't work in general, this might be a way to have one approach that works everywhere. > I think it is important to keep separate notions of scalability > imposed by such a naming scheme and the scalability of the > underlying reality. Here, the reality is messy, and the naming > scheme means that various combinations can coexist peacefully. It > enables having 12 versions at once, but that is the underlying > reality, unless some are prohibited. Of course, not having a > mechanism has the effect of prohibiting this. To me, it seems like the -L/usr/lib/guile/VERSION solution would allow the same result, but without the library naming issues. You'd have: /usr/lib/libguile.so.9* /usr/lib/libguile.so.12* /usr/lib/libguile.so.14* /usr/lib/guile/1.4/libguile.so -> /usr/lib/libguile.so.9.0.1 /usr/lib/guile/1.6/libguile.so -> /usr/lib/libguile.so.12.0.4 /usr/lib/guile/1.8/libguile.so -> /usr/lib/libguile.so.14.0.2 Just to be sure I understand, is your objection to this primarily a concern with it being an untested approach? I just want to make sure we're on the same page. Thanks -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-27 16:54 ` Release now? Rob Browning @ 2003-02-27 18:07 ` Greg Troxel 2003-02-27 18:45 ` Rob Browning 2003-02-27 19:06 ` Rob Browning 1 sibling, 1 reply; 34+ messages in thread From: Greg Troxel @ 2003-02-27 18:07 UTC (permalink / raw) Cc: guile-devel To me, it seems like the -L/usr/lib/guile/VERSION solution would allow the same result, but without the library naming issues. You'd have: /usr/lib/libguile.so.9* /usr/lib/libguile.so.12* /usr/lib/libguile.so.14* /usr/lib/guile/1.4/libguile.so -> /usr/lib/libguile.so.9.0.1 /usr/lib/guile/1.6/libguile.so -> /usr/lib/libguile.so.12.0.4 /usr/lib/guile/1.8/libguile.so -> /usr/lib/libguile.so.14.0.2 Just to be sure I understand, is your objection to this primarily a concern with it being an untested approach? I just want to make sure we're on the same page. No, we're not. My objection, deep down, is a philosophical discomfort with linking against a library in one place and expecting the run-time linker to find it someplace else. This just seems to be Wrong and tempting fate. Maybe I just need to get over this - it is probably a remnant from early exposure to systems that stored the whole path, or SunOS where -R was the default automatically from -L. I think I also have an objection to doing things to accomodate people who refuse to use -rpath, since to me the resulting pseudo-requirement to put all libraries in /usr/lib (or use LD_LIBRARY_PATH) is totally unreasonable. Your proposal does seem likely to impose fairly little pain and save a lot. I would like to make sure that one can have different pkg-config files and select the right one, since IMHO pkg-config will replace guile-config eventually. There is a large transition question, though - guile 1.6 already has libraries in a particular place. For 1.8 to have a new place is probably fine, but this would be disruptive to those who have already found a satisfactory solution. Hence my notion of having the version-named midfix be optional, so Debian can use it and NetBSD can keep using separate prefixes. Also, we might consider having a different prefix rather than a 'midfix', which seems awkward. With /usr/lib/guile/1.4, guile/1.4 gets appended to $(libdir). The alternative of /usr/guile/1.4/lib, where prefix is /usr/guile/1.4 instead of /usr, seems cleaner to me. This latter scheme is in fact what NetBSD does, except that -rpath is used to find the libguile.so at run time from /usr/pkg/guile/1.4/lib, and it isn't present in /usr/lib/libguile.so. So, setting the prefix, and some optional glue code to symlink in the libs (and guile-config with versions) to the 'real' $(prefix)/lib would probably buy us the best of both worlds. And, there would be a harmonized solution between NetBSD and Debian, modulo the 'use -R v.s. make symlinks in /usr/lib' difference. To me, that bodes well for it working elsewhere. (With 20/20 hindsight, guile really should have got this right long ago, but I didn't contribute code/solution then, so I have no absolutely no right to complain.) Summarizing: If the installed locations of guile 1.6 changes, I object because it will cause work for people who have already coped. I prefer the different prefix rather than a midfix. A configure option to add a midfix seems ok, but given that we already have --prefix, it seems like more work. If the default behavior includes either midfixes or extra symlinks, I object, because it is imposing what some may view as uncleanliness on everyone because some decline to use -R. Differing prefixes and a ./configure option to symlink into another prefix is a clean solution which can be used in varying environments, enabling each to win while preserving their sense of the right way to do things. Greg Troxel <gdt@ir.bbn.com> _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-27 18:07 ` Greg Troxel @ 2003-02-27 18:45 ` Rob Browning 2003-02-27 19:25 ` Greg Troxel 0 siblings, 1 reply; 34+ messages in thread From: Rob Browning @ 2003-02-27 18:45 UTC (permalink / raw) Cc: guile-devel Greg Troxel <gdt@ir.bbn.com> writes: > There is a large transition question, though - guile 1.6 already has > libraries in a particular place. For 1.8 to have a new place is > probably fine, but this would be disruptive to those who have already > found a satisfactory solution. Hence my notion of having the > version-named midfix be optional, so Debian can use it and NetBSD can > keep using separate prefixes. Though at least for end-users compiling using guile-config, I'd hope the transition would be rather painless. > Also, we might consider having a different prefix rather than a > 'midfix', which seems awkward. With /usr/lib/guile/1.4, guile/1.4 > gets appended to $(libdir). The alternative of /usr/guile/1.4/lib, > where prefix is /usr/guile/1.4 instead of /usr, seems cleaner to me. I don't really think that's feasible, at least not as the default. At least for most of the linux distributions (and I'd guess solaris, etc.) that would be in contravention of the FHS (and predecessors), and I would guess also the LSB. > Summarizing: > > If the installed locations of guile 1.6 changes, I object because it > will cause work for people who have already coped. Hmm, but I'm only talking about changing the location of one file (a symlink) on the lib side, per library, i.e. libguile.so, which would affect packagers, but shouldn't affect anyone using guile-config. Also we're going to *have* to change the install location of the headers, i.e. /usr/include/guile/VERSION/, at least for normal autoconf style installs, i.e. FHS compliant installs since using /usr/include/libguile.h doesn't allow multiple dev versions to be installed. > I prefer the different prefix rather than a midfix. A configure > option to add a midfix seems ok, but given that we already have > --prefix, it seems like more work. I don't really think this is likely to be acceptable as a default. If you've ever seen the mass objections from *many* unix camps to attempts to violate the FHS-style /usr/lib/*, /usr/include/* approach, you know what I mean. I can understand -- there are good reasons for many of the choices made in the FHS. That doesn't mean we shouldn't have a way to support other approaches. In gnucash we had --enable-opt-style-install. I don't think I'd want to name the option that now, but it arranged for things to be /etc/gnucash/blarg by default, but to be able to be /opt/gnucash/etc/blarg when requested. It was somewhat a pain to arrange and maintain, but it can be done. > If the default behavior includes either midfixes or extra symlinks, > I object, because it is imposing what some may view as uncleanliness > on everyone because some decline to use -R. I think we may just have to agree to disagree here. From the user's perspective, the -L approach should be transparent, and from anyone else's perspective, it should be trivial to either support a --configure option that changes that default, or just let them "mv guilelibdir/* libdir/" in whatever build/install script/infrastructure they're using. Or we could possibly have an option. If what you're arguing for is in fact an "opt-style" install, then that's fine, but I think it'll have to be something that can be enabled rather than the default since it's my impression that FHS style layouts are the definite majority. > Differing prefixes and a ./configure option to symlink into another > prefix is a clean solution I think maybe I still don't have a good impression of what you're preferred solution is (and that's likely my fault) -- I'm not sure what the "prefixes" are here. Overall, I still feel like the changes I've proposed are a fairly small alteration to the current strategy, and seem to be likely to work everywhere. That's what's driving my immediate inclination. And although we may want to do it anyway, having more than one strategy, especially if they're significantly different, does increase the support burden both on the coding side, and on the end-user side. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-27 18:45 ` Rob Browning @ 2003-02-27 19:25 ` Greg Troxel 2003-02-27 20:14 ` Rob Browning 0 siblings, 1 reply; 34+ messages in thread From: Greg Troxel @ 2003-02-27 19:25 UTC (permalink / raw) Cc: guile-devel Though at least for end-users compiling using guile-config, I'd hope the transition would be rather painless. I think I'm almost convinced (and almost is enough) that's true. I don't really think that's feasible, at least not as the default. At least for most of the linux distributions (and I'd guess solaris, etc.) that would be in contravention of the FHS (and predecessors), and I would guess also the LSB. I just went and read parts of FHS, so I see your point on this. That said, GNU software supports letting the user choose the prefix, and we shouldn't lose that, but if our interpretion of where things belong under the prefix includes versioned subdirs that's OK. Also we're going to *have* to change the install location of the headers, i.e. /usr/include/guile/VERSION/, at least for normal autoconf style installs, i.e. FHS compliant installs since using /usr/include/libguile.h doesn't allow multiple dev versions to be installed. Either that or multiple prefixes, and I see that multiple prefixes are frowned upon by the FHS. Since there is no proposal on the table to remove the ability to use --prefix, that's not an issue. If what you're arguing for is in fact an "opt-style" install, then that's fine, but I think it'll have to be something that can be enabled rather than the default since it's my impression that FHS style layouts are the definite majority. I was asking for the current bebavior to be preserved unless someone asks for --version-dirs, which would put things in /usr/lib/guile/1.x instead of /usr/lib (and similarly for /usr/share, etc.). But I guess that really isn't necessary, as long as guile-config-using software can just rebuild and run. So I withdraw this objection. I think maybe I still don't have a good impression of what you're preferred solution is (and that's likely my fault) -- I'm not sure what the "prefixes" are here. I meant: guile14-src $ ./configure --prefix=/usr/pkg/guile/1.4 guile16-src $ ./configure --prefix=/usr/pkg/guile/1.6 guile18-src $ ./configure --prefix=/usr/pkg/guile/1.8 or perhaps one of them being the 'primary' and installed in /usr/pkg directly. But I see how this violate FHS and how people might not like it. And I realize it causes problems in a rpath-prohibited environment. Overall, I still feel like the changes I've proposed are a fairly small alteration to the current strategy, and seem to be likely to work everywhere. That's what's driving my immediate inclination. I may be overestimating their impact. Perhaps if you wrote down precisely what files would get installed in different places, and what extra symlinks would be made (and under what circumstances) this would all be clearer. I just looked through what is in the 1.6 pkg, and see a bunch of things. I'll list them and annotate with what I think you are proposing. Except that I don't get what you mean for libs, so I listed what came to me as I was doing this exercise. Then, it would be good to understand the ripple effects on e.g. having guile-gtk for two guile versions installed - can that just adopt the same scheme? bin/guile bin/guile-snarf bin/guile-config bin/guile-tools put in bin/guile/X.Y, and symlink one to bin/guile presumably the "I want the symlink in the standard place" is a configure option, so it can be assigned to the package denoted as primary by the package system maintainer. Use --primary-symlinks as the configure option, perhaps. include/libguile/__scm.h [...] include/guile/gh.h include/guile/srfi/srfi-4.h include/guile/srfi/srfi-13.h include/guile/srfi/srfi-14.h include/guile-readline/readline.h include/libguile.h put in include/guile/X.Y/{libguile/*,guile/*,libguile.h}, with no symlinks. people should be using guile-config/pkgconfig, so there is no need to have anything work unless the appropiate -I/usr/include/guile/1.4 is given. info/guile.info info/guile.info-1 [...] put in info/guile/X.Y/*, with symlinks from info if the --primary-symlinks option was given. This makes them all available and the primary obtained by default. lib/libguile.a lib/libguile.la lib/libguile.so lib/libguile.so.15 lib/libguile.so.15.0 lib/libguile-ltdl.a lib/libguile-ltdl.la lib/libguile-ltdl.so lib/libguile-ltdl.so.1 lib/libguile-ltdl.so.1.0 lib/libguilereadline-v-12.a lib/libguilereadline-v-12.la lib/libguilereadline-v-12.so lib/libguilereadline-v-12.so.15 lib/libguilereadline-v-12.so.15.0 lib/libguile-srfi-srfi-4-v-1.a lib/libguile-srfi-srfi-4-v-1.la lib/libguile-srfi-srfi-4-v-1.so lib/libguile-srfi-srfi-4-v-1.so.1 lib/libguile-srfi-srfi-4-v-1.so.1.0 lib/libguile-srfi-srfi-13-14-v-1.a lib/libguile-srfi-srfi-13-14-v-1.la lib/libguile-srfi-srfi-13-14-v-1.so lib/libguile-srfi-srfi-13-14-v-1.so.1 lib/libguile-srfi-srfi-13-14-v-1.so.1.0 put in lib/guile/X.Y symlinks for libguile.so.15/15.0 and other libs into lib/ symlinks for libguile.a/libguile.la (?) if --primary-symlinks never a symlink in lib for libguile.so itself err, now I realize this isn't what you mean. I think you have proposed putting the .sos with versions in $(prefix)/lib, and symlinks for libguile.so in the special link-time-only lib. But I don't understand where the .a and .la versions go - is the /usr/lib/guile/X.Y scheme primary, or not? With include files, it is primary, and it's only an accident of so naming that they don't collide for some cases. how about /usr/lib has no guile files, unless --lib-symlinks is given? Then the rpath users will have a clean separation, and those without rpath can pick up libguile.so.{9,10,15} from /usr/lib. share/aclocal/guile.m4 put in share/guile/1.4/aclocal/guile.m4 symlink in share/aclocal if --primary-symlinks share/guile/1.6/oop/goops/active-slot.scm [...] already versioned. No changes needed. So I realize now that I don't understand what you propose in terms of moving libraries. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-27 19:25 ` Greg Troxel @ 2003-02-27 20:14 ` Rob Browning 0 siblings, 0 replies; 34+ messages in thread From: Rob Browning @ 2003-02-27 20:14 UTC (permalink / raw) Cc: guile-devel Greg Troxel <gdt@ir.bbn.com> writes: > Either that or multiple prefixes, and I see that multiple prefixes are > frowned upon by the FHS. Since there is no proposal on the table to > remove the ability to use --prefix, that's not an issue. We'd definitely keep --prefix. I think many of us use it all the time, even under a distribution like Debian/RH, etc. for local compiles. > guile14-src $ ./configure --prefix=/usr/pkg/guile/1.4 > guile16-src $ ./configure --prefix=/usr/pkg/guile/1.6 > guile18-src $ ./configure --prefix=/usr/pkg/guile/1.8 Sure, I'd expect this to still work fine. > Then, it would be good to understand the ripple effects on e.g. having > guile-gtk for two guile versions installed - can that just adopt the > same scheme? Maybe -- now that we're talking about this again, I have the feeling that I thought about the -L/usr/lib/guile/VERSION trick a while back and rejected it for some reason :/ But if it works for guile, others should also be able to use /usr/lib/FOO/VERSION for their own version specific .so -> ../../libFOO.so.X.Y.Z symlinks. > bin/guile > bin/guile-snarf > bin/guile-config > bin/guile-tools > put in bin/guile/X.Y, and symlink one to bin/guile Actually I was thinking of ${bindir}/guile-X.Y{,-snarf,-config,...}, and perhaps an easy way to create the non-versioned symlinks. this means that in the pkg approach, you'd probably have /usr/pkg/guile/1.4/bin/guile-1.4, etc., unless we arranged for --opt-style-install or similar. > include/libguile.h > put in include/guile/X.Y/{libguile/*,guile/*,libguile.h}, with no symlinks. > people should be using guile-config/pkgconfig, so there is no need > to have anything work unless the appropiate > -I/usr/include/guile/1.4 is given. right. > info/guile.info > info/guile.info-1 > [...] > put in info/guile/X.Y/*, with symlinks from info if the > --primary-symlinks option was given. This makes them all available > and the primary obtained by default. This one is somewhat harder if we have any cross-links. AFAIK there's still no good solution for this, and if there is one, I'd *love* to hear about it. It's a real pain wrt the emacsen... > lib/libguile.a what I was thanking about is lib/guile/1.8/libguile.a lib/guile/1.8/libguile.la lib/guile/1.8/libguile.so -> ../../libguile.so.15.0.0 lib/libguile.so.15 lib/libguile.so.15.0 lib/libguile.so.15.0.0 of course as I mentioned, we may have to have an enhanced ltdl before this would work because we'd really need something like lib/libguile.la.15.0.0 rather than the above .la file. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-27 16:54 ` Release now? Rob Browning 2003-02-27 18:07 ` Greg Troxel @ 2003-02-27 19:06 ` Rob Browning 2003-02-27 19:13 ` Rob Browning 1 sibling, 1 reply; 34+ messages in thread From: Rob Browning @ 2003-02-27 19:06 UTC (permalink / raw) Cc: guile-devel Rob Browning <rlb@defaultvalue.org> writes: > /usr/lib/guile/1.4/libguile.so -> /usr/lib/libguile.so.9.0.1 > /usr/lib/guile/1.6/libguile.so -> /usr/lib/libguile.so.12.0.4 > /usr/lib/guile/1.8/libguile.so -> /usr/lib/libguile.so.14.0.2 Ahh, the potential fatal flaw -- where to the *.la libraries go, and how does this strategy affect the current ltdl? My guess is that until we get versioning for ltdl and so can have /usr/lib/libguile-foo-bar.la.2.4.1 so that ltdl can find the right one, we may not be able to use the strategy for the .so's above... -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-27 19:06 ` Rob Browning @ 2003-02-27 19:13 ` Rob Browning 2003-02-27 19:36 ` Greg Troxel 0 siblings, 1 reply; 34+ messages in thread From: Rob Browning @ 2003-02-27 19:13 UTC (permalink / raw) Cc: guile-devel Rob Browning <rlb@defaultvalue.org> writes: > /usr/lib/libguile-foo-bar.la.2.4.1 > > so that ltdl can find the right one, we may not be able to use the > strategy for the .so's above... Though thinking further, maybe this is only a problem for libguile, and people are a lot less likely to want to dynamic-link specific versions of that, though that doesn't mean they'll never need to. Putting the guile version in the lib name would fix that too, but I think there's still a reasonably strong sentiment against libguile-12-gwrap-glib-2-gl-3-whatever-4. I guess the right way to start is still probably to see if we can fix libtool and/or libguile-ltdl, and if so, that'll change the range of available options... -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-27 19:13 ` Rob Browning @ 2003-02-27 19:36 ` Greg Troxel 2003-02-27 20:02 ` Rob Browning 0 siblings, 1 reply; 34+ messages in thread From: Greg Troxel @ 2003-02-27 19:36 UTC (permalink / raw) Cc: guile-devel Putting the guile version in the lib name would fix that too, but I think there's still a reasonably strong sentiment against libguile-12-gwrap-glib-2-gl-3-whatever-4. But is the sentiment well founded? We've gone down the path of lib symlinks, and it seems that it really is pretty hairy. I hold up glib 1.2/2 as an example of a low-pain solution to what would otherwise have been a very painful and chaotic transition. Right now we are perhaps 0.2 to 0.3 of the way through it, and tons of people have both versions - and both versions of dependent stuff like ORBit - installed at the same time. Over time more libraries will move to the glib2 world, and programs as all the libraries are available, and eventually people won't need glib 1.2. Granted, this is way more complicated than guile, but it's an excellent example of a long chain of library dependencies when the base library has a major change. Granted, you can't do this often, and guile should try to do it no more often than once every 5 years, but the coping mechanism seems to work. And I would suggest not keying on major numbers, but on compile time changes, and thus the release numbers. This only need be for when 'recompile everything' isn't a good answer. libguile14 and libguile16 will be less confsing, IMHO. Or does debian insist on upgrading a package without upgrading things that depend on it? If so, I think one has to have a new package name that can coexist on every incompatible change. (NetBSD's make update does a pkg_delete -r and then rebuilds all the depending packages.) Greg Troxel <gdt@ir.bbn.com> _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-27 19:36 ` Greg Troxel @ 2003-02-27 20:02 ` Rob Browning 2003-02-27 20:54 ` Greg Troxel 0 siblings, 1 reply; 34+ messages in thread From: Rob Browning @ 2003-02-27 20:02 UTC (permalink / raw) Cc: guile-devel Greg Troxel <gdt@ir.bbn.com> writes: > Putting the guile version in the lib name would fix that too, but I > think there's still a reasonably strong sentiment against > libguile-12-gwrap-glib-2-gl-3-whatever-4. > > But is the sentiment well founded? We've gone down the path of lib > symlinks, and it seems that it really is pretty hairy. > > I hold up glib 1.2/2 as an example of a low-pain solution to what > would otherwise have been a very painful and chaotic transition. How do they handle it, and do they have the same dynamic-link issues? Also, how do they handle the app1 -> libfoo -> libgtk, and app1 -> libbar -> libbgtk with respect to upgrading, during the the period when libfoo has been recompiled against the new libgtk, but libbar on the system hasn't -- do they just require all libraries in the chain to mention the versions of all the other libs they're linked against? > And I would suggest not keying on major numbers, but on compile time > changes, and thus the release numbers. Well it's actually the major numbers that are required to indicate binary compatibility, so they're the most "correct" indicator in general. However in guile, we've committed to changing all the lib major numbers with each major release, so they're effectively equivalent. > Or does debian insist on upgrading a package without upgrading > things that depend on it? Right now Debian actually packages all the guile libs in guile-1.6-libs, but that's only possible because we're planning to bump the major sonames with every major release. If we didn't then binary packaging systems would have to have one binary package per lib, i.e. libguile12*.deb, libguile-srfi*.deb, to accomodate for the possibility that we might change the soname for some libs, but not all of them in a given major release (i.e. unless we bump all of them, guile-1.8-libs would have files that conflicted with guile-1.6-libs). > If so, I think one has to have a new package name that can coexist > on every incompatible change. (NetBSD's make update does a > pkg_delete -r and then rebuilds all the depending packages.) One thing to keep in mind is that with a source-based distribution like bsd or gentoo, many of these problems go away. Having to support multiple versions of installed binary packages definitely complicates things. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-27 20:02 ` Rob Browning @ 2003-02-27 20:54 ` Greg Troxel 2003-02-27 21:07 ` Dale P. Smith ` (2 more replies) 0 siblings, 3 replies; 34+ messages in thread From: Greg Troxel @ 2003-02-27 20:54 UTC (permalink / raw) Cc: guile-devel {list: I have received no hate mail for ranting so I presume this is welcome; feel free to tell me otherwise!} > I hold up glib 1.2/2 as an example of a low-pain solution to what > would otherwise have been a very painful and chaotic transition. How do they handle it, and do they have the same dynamic-link issues? Also, how do they handle the app1 -> libfoo -> libgtk, and app1 -> libbar -> libbgtk with respect to upgrading, during the the period when libfoo has been recompiled against the new libgtk, but libbar on the system hasn't -- do they just require all libraries in the chain to mention the versions of all the other libs they're linked against? libfoo stays with glib/gtk, and libfoo2 is built against glib2/gtk2. For some things, the libraries have more substantial changes and have entirely new names (see linc below, which is a 2-world thing only): For foo = ORBit: poblano gdt 997 ~ > ldd /usr/pkg/lib/libORBit.so /usr/pkg/lib/libORBit.so: -lglib.13 => /usr/pkg/lib/libglib.so.13 -lm.0 => /usr/lib/libm387.so.0 -lm.0 => /usr/lib/libm.so.0 -lintl.0 => /usr/lib/libintl.so.0 poblano gdt 1010 ~ > ldd /usr/pkg/bin/orbit-idl /usr/pkg/bin/orbit-idl: -lglib.13 => /usr/pkg/lib/libglib.so.13 -lIDL.0 => /usr/pkg/lib/libIDL.so.0 -lgmodule.13 => /usr/pkg/lib/libgmodule.so.13 -lm.0 => /usr/lib/libm387.so.0 -lm.0 => /usr/lib/libm.so.0 -lintl.0 => /usr/lib/libintl.so.0 -lc.12 => /usr/lib/libc.so.12 poblano gdt 998 ~ > ldd /usr/pkg/lib/libORBit-2.so /usr/pkg/lib/libORBit-2.so: -lm.0 => /usr/lib/libm387.so.0 -lm.0 => /usr/lib/libm.so.0 -liconv.3 => /usr/pkg/lib/libiconv.so.3 -lintl.0 => /usr/lib/libintl.so.0 -lglib-2.0.200 => /usr/pkg/lib/libglib-2.0.so.200 -lgobject-2.0.200 => /usr/pkg/lib/libgobject-2.0.so.200 -lpthread.14 => /usr/pkg/lib/libpthread.so.14 -lgthread-2.0.200 => /usr/pkg/lib/libgthread-2.0.so.200 -llinc.1 => /usr/pkg/lib/liblinc.so.1 -lgmodule-2.0.200 => /usr/pkg/lib/libgmodule-2.0.so.200 -lpopt.0 => /usr/pkg/lib/libpopt.so.0 poblano gdt 1011 ~ > ldd /usr/pkg/bin/orbit-idl-2 /usr/pkg/bin/orbit-idl-2: -lpopt.0 => /usr/pkg/lib/libpopt.so.0 -lm.0 => /usr/lib/libm387.so.0 -lm.0 => /usr/lib/libm.so.0 -liconv.3 => /usr/pkg/lib/libiconv.so.3 -lintl.0 => /usr/lib/libintl.so.0 -lglib-2.0.200 => /usr/pkg/lib/libglib-2.0.so.200 -lIDL-2.0 => /usr/pkg/lib/libIDL-2.so.0 -lgobject-2.0.200 => /usr/pkg/lib/libgobject-2.0.so.200 -lgmodule-2.0.200 => /usr/pkg/lib/libgmodule-2.0.so.200 -lc.12 => /usr/lib/libc.so.12 There are 2 parallel worlds, one rooted on glib 1.2, and one on glib-2.0. This indeed doesn't scale, but it's the underlying interface changes that break compiling that don't scale. But it isn't quite that bad, since in the guile world one would have the last guile-gtk version that worked with guile 14, and one that works with 16. Then there is gnome-guile that does glib2/gtk2/ORBit2, and probably that would be built for the new guile only. Well it's actually the major numbers that are required to indicate binary compatibility, so they're the most "correct" indicator in general. However in guile, we've committed to changing all the lib major numbers with each major release, so they're effectively equivalent. Consider a change that breaks binary compatibility but not compile compatibility, say because there was a function and now it's a macro and invokes some compatibility glue. You have to bump the so number, but upgrading the guile version doesn't require upstream maintainers to do anything different, except maybe recompile. This kind of change doesn't hurt that badly in the package maintainer viewpoint, since it doesn't force having to be able to compile against two versions at once. One thing to keep in mind is that with a source-based distribution like bsd or gentoo, many of these problems go away. Having to support multiple versions of installed binary packages definitely complicates things. It does, but named versions does this. It looks ugly, but that's because with a chain of n libs, you have 2^n versions. Perhaps this is all a red herring and we can preserve compile-time compatibility adequately. Keeping the old libs around seems to be a good solution for running old binaries. In the specific case of Gnucash, what about 1.6 made gnucash 1.6.8 not buildable, and was that something that wasn't deprecated in 1.4? We may be solving the wrong problem. Greg Troxel <gdt@ir.bbn.com> _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-27 20:54 ` Greg Troxel @ 2003-02-27 21:07 ` Dale P. Smith 2003-02-27 21:30 ` Dale P. Smith 2003-02-27 21:47 ` Rob Browning 2003-04-25 19:26 ` Neil Jerram 2 siblings, 1 reply; 34+ messages in thread From: Dale P. Smith @ 2003-02-27 21:07 UTC (permalink / raw) On 27 Feb 2003 15:54:23 -0500 Greg Troxel <gdt@ir.bbn.com> wrote: > {list: I have received no hate mail for ranting so I presume this is > welcome; feel free to tell me otherwise!} > The guile-* lists are nice, warm, friendly place ... as long as you don't bring up the issue of #f not being eq? to '() ;^) -Dale -- Dale P. Smith Senior Systems Consultant, | Treasurer, Altus Technologies Corporation | Cleveland Linux Users Group dsmith@altustech.com | http://cleveland.lug.net 440-746-9000 x239 | _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-27 21:07 ` Dale P. Smith @ 2003-02-27 21:30 ` Dale P. Smith 0 siblings, 0 replies; 34+ messages in thread From: Dale P. Smith @ 2003-02-27 21:30 UTC (permalink / raw) On Thu, 27 Feb 2003 16:07:36 -0500 "Dale P. Smith" <dsmith@altustech.com> wrote: Please forgive me, I meant that as private mail, not sent to the list. -Dale -- Dale P. Smith Senior Systems Consultant, | Treasurer, Altus Technologies Corporation | Cleveland Linux Users Group dsmith@altustech.com | http://cleveland.lug.net 440-746-9000 x239 | _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-27 20:54 ` Greg Troxel 2003-02-27 21:07 ` Dale P. Smith @ 2003-02-27 21:47 ` Rob Browning 2003-04-25 19:26 ` Neil Jerram 2 siblings, 0 replies; 34+ messages in thread From: Rob Browning @ 2003-02-27 21:47 UTC (permalink / raw) Cc: guile-devel Greg Troxel <gdt@ir.bbn.com> writes: > {list: I have received no hate mail for ranting so I presume this is > welcome; feel free to tell me otherwise!} Well I'm interested, so don't worry about it :> > There are 2 parallel worlds, one rooted on glib 1.2, and one on > glib-2.0. This indeed doesn't scale, but it's the underlying > interface changes that break compiling that don't scale. But it > isn't quite that bad, since in the guile world one would have the > last guile-gtk version that worked with guile 14, and one that works > with 16. Then there is gnome-guile that does glib2/gtk2/ORBit2, and > probably that would be built for the new guile only. Ahh, ok, thx. One of the more aggravating questions which we've already discussed to death here and on debian-devel, is how do I handle allowing people to build the current version of g-wrap for either guile 1.4 or guile 1.6 -- i.e. unless I embed the guile version in g-wrap's libs' names (or the sonames), then there's no way to pick a "correct" soname. > Perhaps this is all a red herring and we can preserve compile-time > compatibility adequately. Keeping the old libs around seems to be a > good solution for running old binaries. In the specific case of > Gnucash, what about 1.6 made gnucash 1.6.8 not buildable, and was that > something that wasn't deprecated in 1.4? We may be solving the wrong > problem. AFAIK gnucash just needed to be ported/updated. I actually did that work some time back for another project, but I don't think I preserved the ability to use both guile 1.4 and guile 1.6, and at the time I believe that would have been a problem. I haven't been involved much with gnucash lately, so I don't know where they actually stand on that front, and unfortunately I don't think I have those changes anymore. However, as far as I recall, I got gnucash working fine with guile 1.5.X. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-27 20:54 ` Greg Troxel 2003-02-27 21:07 ` Dale P. Smith 2003-02-27 21:47 ` Rob Browning @ 2003-04-25 19:26 ` Neil Jerram 2 siblings, 0 replies; 34+ messages in thread From: Neil Jerram @ 2003-04-25 19:26 UTC (permalink / raw) Cc: Rob Browning [this is a very delayed reply to the thread about how to handle multiple simultaneously installed Guile versions] >>>>> "Greg" == Greg Troxel <gdt@ir.bbn.com> writes: Greg> {list: I have received no hate mail for ranting so I presume Greg> this is welcome; feel free to tell me otherwise!} Your contributions here are very welcome. So far, this issue seems to run and run without ever being quite resolved; it would be wonderful to finally come up with a solution that everyone is happy with. Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-25 13:34 ` Marius Vollmer 2003-02-25 16:08 ` Greg Troxel @ 2003-02-25 16:28 ` Andreas Rottmann 1 sibling, 0 replies; 34+ messages in thread From: Andreas Rottmann @ 2003-02-25 16:28 UTC (permalink / raw) Cc: Greg Troxel Marius Vollmer <marius.vollmer@uni-dortmund.de> writes: > Greg Troxel <gdt@ir.bbn.com> writes: > >> I'm all for shorter intervals between releases, but it would be good >> to make sure that packages expecting 1.6 can work with 1.8 (modulo >> insisting on a specific version when it isn't necessary, which is easy >> to patch). > > Yes, we definitely need to be able to have two versions of Guile > installed with the same prefix and have them be usable for running > programs. However, I don't think we need to make special arrangements > for being able to compile against two versions of Guile at the same > time. Having to use different prefices for the two versions seems > acceptable to me. > > Would pkg-config address this issue? I.e. could one say `guile-config > --use-version 1.6 link` (or something similar) with the effect that > the right '-L' and '-R' options are spit out? > If you talk of pkg-config[0], you could easily have this by simply installing two .pc files (named for example, guile-1.6.pc and guile-1.8.pc) in $(prefix)/lib/pkgconfig. You'd then call `pkg-config --libs guile-1.6' to get the right -L and -R options... Regards, Andy [0] http://www.freedesktop.org/software/pkgconfig/ -- Andreas Rottmann | Dru@ICQ | 118634484@ICQ | a.rottmann@gmx.at http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-24 12:37 Release now? Mikael Djurfeldt 2003-02-24 13:08 ` Dale P. Smith 2003-02-24 13:32 ` Greg Troxel @ 2003-02-24 18:35 ` Rob Browning 2003-02-25 13:20 ` Marius Vollmer 3 siblings, 0 replies; 34+ messages in thread From: Rob Browning @ 2003-02-24 18:35 UTC (permalink / raw) Cc: Marius Vollmer Mikael Djurfeldt <mdj@kvast.blakulla.net> writes: > When Rob has added the GMP support there's only the signal handling > left of the major changes intended for the 1.8 release, right? Well, the GMP support isn't in the tree yet. I'm actually trying to evaluate it and was planning to send a message to guile-devel about it today. Stay tuned. Although I agree that shorter release periods might be a good idea, I'd be more likely to shoot for say once or twice a year for major releases unless we have good reason to do otherwise. Of course I'm not sure this contradicts what you're suggesting. However I do feel that trying to release in the next month or two would be a little early. Guile 1.6 isn't even in Debian yet, although I warned the other relevant maintainers last week that I'd be moving it from the staging area to unstable at the start of this week (i.e. I'll be uploading to unstable shortly). Once it does go into unstable, if history is any guide, it'll still be a while before all the relevant maintainers have even finished shifting over and uploading new packages. If we can afford it, I'd tend to argue in favor of at least some period of stability, to let this version "settle". This concern by itself wouldn't necessarily be enough to argue in favor of waiting a while, but I'd also like to wait until we get the performance of 1.7 to be more comparable to 1.6. I believe the recent macro system cleanups have cost us quite a bit of performance, and while I still think they're absolutely the right thing to do, I'd like to get them completely finished (where do we stand? do we still have "execution-time" expansions?), and then work on performance a bit. I've been spending quite a bit of time over the past few weeks trying to figure out what possibilities might be available to us wrt to performance going forward, once we have macroexpansion separated from evaluation, including an interesting discussion with one of the gcc maintainers :> As an example of the performance issue, the following test just takes 400000 pre-generated random bignum pairs and applies a given operator to each of the pairs, ignoring the result. Note that this is a quick-hack benchmark-wise, and so feel free to criticize it as such :> The core code: (define (bench-random-int-op op) (let loop ((x-vals random-x-values) (y-vals random-y-values)) (if (pair? x-vals) (begin (op (car x-vals) (car y-vals)) (loop (cdr x-vals) (cdr y-vals)))))) The results: $ ./run-benchmark guile-1.6 ./guile-1.7 foo.scm starting trials ("bench-random-op +" "guile-1.6" ((user . 199) (sys . 0) (gc . 89))) ("bench-random-op -" "guile-1.6" ((user . 178) (sys . 0) (gc . 57))) ("bench-random-op *" "guile-1.6" ((user . 220) (sys . 0) (gc . 101))) ("bench-random-op /" "guile-1.6" ((user . 264) (sys . 0) (gc . 118))) ("bench-random-op gcd" "guile-1.6" ((user . 123) (sys . 0) (gc . 43))) ("bench-random-op lcm" "guile-1.6" ((user . 278) (sys . 0) (gc . 119))) starting trials ("bench-random-op +" "./guile-1.7" ((user . 341) (sys . 1) (gc . 61))) ("bench-random-op -" "./guile-1.7" ((user . 315) (sys . 0) (gc . 60))) ("bench-random-op *" "./guile-1.7" ((user . 352) (sys . 0) (gc . 55))) ("bench-random-op /" "./guile-1.7" ((user . 382) (sys . 0) (gc . 54))) ("bench-random-op gcd" "./guile-1.7" ((user . 267) (sys . 0) (gc . 56))) ("bench-random-op lcm" "./guile-1.7" ((user . 374) (sys . 0) (gc . 54))) Also, with respect to a comment you made to Dale later on: > If we then initiate the release process, chances are that the > release won't happen until summer, so 1.6 will have at least half a > year of "life". So, "now" means "in half a year". But if we don't > start to plan for it now, it will be longer... Though I can definitely see why you'd be concerned about this, I'm hoping to handle the next release somewhat differently than the last one. I believe I unintentionally branched too early last time, and that contributed quite a bit to the delay. This time I don't want to branch until *much* later in the process. I'd like for us to all work to get things to a state where we think we're just about ready to release and then branch. I believe that will let us move much more quickly. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-24 12:37 Release now? Mikael Djurfeldt ` (2 preceding siblings ...) 2003-02-24 18:35 ` Rob Browning @ 2003-02-25 13:20 ` Marius Vollmer 2003-03-03 14:06 ` Mikael Djurfeldt 2003-04-25 19:28 ` Neil Jerram 3 siblings, 2 replies; 34+ messages in thread From: Marius Vollmer @ 2003-02-25 13:20 UTC (permalink / raw) Cc: guile-devel Mikael Djurfeldt <mdj@kvast.blakulla.net> writes: > When Rob has added the GMP support there's only the signal handling > left of the major changes intended for the 1.8 release, right? There is also the issue of having good replacements for all of gh_. Also, the deprecation mechanism should be made more user-oriented and be controlled with a macro like _GNU_SOURCE. Also also, I promised rms to keep backwards compatability for a long time (and I do agree that it is important). That means that the things that are deprecated in 1.6 and have already been removed from 1.8 need to be added back. I understand that this is an unwelcome mass of uninteresting work and I'm willing to do it myself, of course, eventually... :-/ > I think it would be a good idea to aim for release of 1.8 after these > two components have been added. This since people have asked for > shorter intervals between releases. > > What do you say? We should first complete the points mentioned for 1.8 in tasks/TODO. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-25 13:20 ` Marius Vollmer @ 2003-03-03 14:06 ` Mikael Djurfeldt 2003-04-25 19:28 ` Neil Jerram 1 sibling, 0 replies; 34+ messages in thread From: Mikael Djurfeldt @ 2003-03-03 14:06 UTC (permalink / raw) Cc: djurfeldt (Sorry for answering lately---been on vacation!) Marius Vollmer <marius.vollmer@uni-dortmund.de> writes: > Mikael Djurfeldt <mdj@kvast.blakulla.net> writes: > >> When Rob has added the GMP support there's only the signal handling >> left of the major changes intended for the 1.8 release, right? > > There is also the issue of having good replacements for all of gh_. I guess what I'm suggesting is to split the currently planned 1.8 into a leaner 1.8 and a 1.10, i.e., to make 1.8 less ambitious in order to get out bugfixes and new technology faster. The gh_ stuff (and other things in the current 1.8 TODO list) could be done in 1.10. > Also also, I promised rms to keep backwards compatability for a long > time (and I do agree that it is important). That means that the > things that are deprecated in 1.6 and have already been removed from > 1.8 need to be added back. Yes, this would be a typical lean 1.8 thing, and is a good argument why a lean 1.8 release wouldn't be painful. I just want to add that this is only a suggestion. While I think it would be good to make a lean 1.8 release, I'm not going to argue further for it. :-) M _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-02-25 13:20 ` Marius Vollmer 2003-03-03 14:06 ` Mikael Djurfeldt @ 2003-04-25 19:28 ` Neil Jerram 2003-04-25 22:59 ` Marius Vollmer 1 sibling, 1 reply; 34+ messages in thread From: Neil Jerram @ 2003-04-25 19:28 UTC (permalink / raw) Cc: Mikael Djurfeldt >>>>> "Marius" == Marius Vollmer <marius.vollmer@uni-dortmund.de> writes: Marius> Also, the deprecation mechanism should be made more Marius> user-oriented and be controlled with a macro like Marius> _GNU_SOURCE. Marius> Also also, I promised rms to keep backwards compatability Marius> for a long time (and I do agree that it is important). Marius> That means that the things that are deprecated in 1.6 and Marius> have already been removed from 1.8 need to be added back. Marius> I understand that this is an unwelcome mass of Marius> uninteresting work and I'm willing to do it myself, of Marius> course, eventually... :-/ These two `also's could be closely related, couldn't they? Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release now? 2003-04-25 19:28 ` Neil Jerram @ 2003-04-25 22:59 ` Marius Vollmer 0 siblings, 0 replies; 34+ messages in thread From: Marius Vollmer @ 2003-04-25 22:59 UTC (permalink / raw) Cc: Mikael Djurfeldt Neil Jerram <neil@ossau.uklinux.net> writes: > >>>>> "Marius" == Marius Vollmer <marius.vollmer@uni-dortmund.de> writes: > > Marius> Also, the deprecation mechanism should be made more > Marius> user-oriented and be controlled with a macro like > Marius> _GNU_SOURCE. > > Marius> Also also, I promised rms to keep backwards compatability > Marius> for a long time (and I do agree that it is important). > Marius> That means that the things that are deprecated in 1.6 and > Marius> have already been removed from 1.8 need to be added back. > Marius> I understand that this is an unwelcome mass of > Marius> uninteresting work and I'm willing to do it myself, of > Marius> course, eventually... :-/ > > These two `also's could be closely related, couldn't they? Yes, they are related, but they can be worked on independently. I hope that the 'per-inclusion' activation of deprecated things can be done without changing our current internal method of marking things as deprecated. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2003-05-16 23:21 UTC | newest] Thread overview: 34+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-02-24 12:37 Release now? Mikael Djurfeldt 2003-02-24 13:08 ` Dale P. Smith 2003-02-24 13:21 ` Mikael Djurfeldt 2003-02-24 13:32 ` Greg Troxel 2003-02-25 13:34 ` Marius Vollmer 2003-02-25 16:08 ` Greg Troxel 2003-02-25 18:38 ` Rob Browning 2003-02-26 1:51 ` Greg Troxel 2003-02-26 2:27 ` Rob Browning 2003-02-27 14:25 ` Greg Troxel 2003-02-27 15:21 ` pkg-config support for guile Greg Troxel 2003-03-22 23:31 ` Marius Vollmer 2003-04-23 21:22 ` Greg Troxel 2003-05-16 23:21 ` Marius Vollmer 2003-02-27 16:54 ` Release now? Rob Browning 2003-02-27 18:07 ` Greg Troxel 2003-02-27 18:45 ` Rob Browning 2003-02-27 19:25 ` Greg Troxel 2003-02-27 20:14 ` Rob Browning 2003-02-27 19:06 ` Rob Browning 2003-02-27 19:13 ` Rob Browning 2003-02-27 19:36 ` Greg Troxel 2003-02-27 20:02 ` Rob Browning 2003-02-27 20:54 ` Greg Troxel 2003-02-27 21:07 ` Dale P. Smith 2003-02-27 21:30 ` Dale P. Smith 2003-02-27 21:47 ` Rob Browning 2003-04-25 19:26 ` Neil Jerram 2003-02-25 16:28 ` Andreas Rottmann 2003-02-24 18:35 ` Rob Browning 2003-02-25 13:20 ` Marius Vollmer 2003-03-03 14:06 ` Mikael Djurfeldt 2003-04-25 19:28 ` Neil Jerram 2003-04-25 22:59 ` Marius Vollmer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).