The current ebuilds for dev-libs/slib seem to assume that the only valid Scheme interpreter is Guile; at least two other Scheme interpreters are currently in Portage: mit-scheme and mzscheme (both of which are supported by slib).
I'm also currently writing an ebuild for SISC (http://sisc.sf.net) which also supports slib. (Not submitted for inclusion in Portage yet because of this issue).
To solve the problem, I propose the following:
1) A virtual "dev-lisp/scheme" package is added. It can be provided by guile, mit-scheme, mzscheme and any other Scheme implementation. (Defaulting to guile, but since these implementations are quite different, I would imagine that most other packages would still depend on a particular Scheme implementation).
2) slib is changed to depend on this virtual "dev-lisp/scheme" package instead of depending specifically on guile. Since packages which currently depend on slib presumably also depend explicitly on guile, this should not cause any problems with existing ebuilds.
3) the install location of slib is changed to the more generic /usr/share/slib. If necessary, symlinks can be created from the "site" directory of each of the Scheme implementations to this directory (upon installing slib).
4) the current postinstall procedure is changed to include module registration for the other Schemes which support slib. I have no interest in adding support for mit-scheme or mzscheme, but will add the code required for SISC. The current registration procedure for Guile does not have be changed, it just needs to check that guile is actually installed before attempting the registration.
An alternative approach to point 4 is to just create slib-guile, slib-sisc, etc. ebuilds which do the necessary work for each individual Scheme implementation (and install into their specific directories), but I think it would be much better for maintainability if the "unified ebuild" approach were taken.
I think all of the above modifications are necessary for being able to properly supporting slib in any non-guile Scheme implementation. I would be quite happy to do the necessary changes to the slib ebuilds, if the maintainers think that this is a sensible course of action.
Steps to Reproduce:
Sorry for taking so long to get back to you.
I'm the defacto maintainer for slib, but don't really know much about it.
Points 1,2 and 3 should be pretty straight-forward
Point 4 I agree with you about keeping the unified ebuild.
I'll look into doing this soon. If you have done any work locally towards this, feel free to attach.
Created attachment 28726 [details]
This ebuild demonstrates the general idea:
0) Depends changed from >=guile-1.4 to virtual/scheme. (Of course, the virtual
must be added and PROVIDE=virtual/scheme must be added to the Guile ebuild for
the dependencies to work properly).
1) Installs into /usr/share/slib.
2) If guile is installed, installs symlink from /usr/share/guile/site/slib to
/usr/share/slib, so that everything works as before.
3) I've added a commented-out section showing how SISC would be handled.
(Haven't finished the ebuild for that yet, so this is just an example).
I've tested that the package registration thingy does the right thing on my
system, but I haven't actually tried *using* slib from Guile.
Just an update to let you know I am still working on this, but at a rather slow pace unfortunately. Hoping to have something this week though.
How is this coming along? I've just installed mit-scheme and may install others
(I already have guile). I'd suggest /usr/share/scheme/slib instead of
/usr/share/slib because there may be many more scheme libraries in future. Also,
shouldn't this package be in dev-scheme rather than dev-libs?
On a related note I see scheme implementations spread out over dev-lisp,
dev-util, dev-lang and dev-scheme. This is very inconvenient and confusing.
antarus@kyoto ~/code/pkgcore/bin $ time ./pquery --revdep=dev-libs/slib -v
description: A personal finance manager
description: A personal finance manager.
description: A tool for exporting C libraries into Scheme
(In reply to comment #5)
A better one :)
# pquery --raw --revdep dev-libs/slib
Matt, your input on this would be greatly appreciated!
Actually I think slib shouldn't depend on any scheme implementation, including a virtual. Instead I think that each Scheme implementation that supports slib should have a use flag to enable support for it and which would turn on slib as a dependency and install slib for that implementation. (Slib has some documentation for how to do that.)
Of course it is also possible to have slib use-flag depend on all available scheme implementations and do the installation, but I don't think that is the right way. All slib stuff would be in one place, but the ebuilds for every Scheme implementation with support for slib would be in two places. Every time you'd install a new implementation you would have to remerge slib too.
A virtual/scheme might be useful if say gnucash would support multiple scheme implementations and another package too and both sets would be exactly the same. Otherwise we'd need virtual/gnucash-scheme and virtual/<other>-scheme which would defeat the purpose of having a virtual. Maybe r6rs will get us there.
Created attachment 104455 [details]
New ebuild for 3a4 with versioning magic by masterdriverz.
doesn't depend on anything except unzip and doesn't install itself for any implementation. I think as it should be.
Created attachment 104500 [details]
with working version magic this time
There seems to be a problem with guile-1.8.1 and slib-3a4: http://www.mail-archive.com/bug-guile%40gnu.org/msg03930.html
I'm also getting:
ERROR: Unbound variable: slib:features
but not the ABORT stuff. I tried the suggested patch, but it doesn't seem to help.
Created attachment 104580 [details]
better new install location, improved version magic without external executable (tr), works with guile-1.6.8 ebuild.
This version depends on the scheme implementation to do the installation, so it will not work with older versions of guile-ebuild than 1.6.8.
Actually I now, after some experience, think it is stupid to let scheme implementations have an slib use flag. It doesn't affect compilation of the scheme implementation at all, but if it is changed recompilation is what will result. Unnecessary recompilation is very annoying.
I think the same problem will result once more implementations get gentoo support for slib. Some may want to compile slib. The best solution I can now think of is to create new ebuilds for installing slib for a particular scheme implementation, such as "slib-for-guile", "slib-for-mzscheme" etc.
(In reply to comment #11)
> There seems to be a problem with guile-1.8.1 and slib-3a4:
> I'm also getting:
> ERROR: Unbound variable: slib:features
> but not the ABORT stuff. I tried the suggested patch, but it doesn't seem to
(In reply to bug #125468, comment #26)
> From http://www.gnu.org/software/guile-gnome/
> "Also note that we have bumped our dependency on G-Wrap to an as-yet-unreleased
> version, and removed the dependency on SLIB."
> So can you really use slib functions from guile-1.8.*?
squirrel guile # guile
guile> (use-modules (ice-9 slib)) ;; before ice-9/slib.scm workaround
ERROR: Unbound variable: slib:features
guile> (use-modules (ice-9 slib)) ;; after ice-9/slib.scm workaround
WARNING: (guile-user): imported module (ice-9 slib) overrides core binding `provided?'
WARNING: (guile-user): imported module (ice-9 slib) overrides core binding `provide'
guile> (require 'new-catalog) ;; create catalog
guile> (real-exp 1) ;; new in slib 3.1.4 but not loaded
In standard input:
3: 0* (real-exp 1)
standard input:3:1: In expression (real-exp 1):
standard input:3:1: Unbound variable: real-exp
guile> (require 'srfi-94) ;; load real-exp, real-ln
guile> (real-exp 1)
guile> (real-ln (real-exp 1))
I'm leaning towards introducing an ebuild guile-slib, but I want to get slib working with a Scheme compiler first, before deciding on a fix. mit-scheme, gambit or maybe SISC, chicken or PLT/Dr/MzScheme.