Summary: | dev-libs/slib incorrectly depends on guile | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bardur Arantsson <bugs-gentoo.org> |
Component: | Current packages | Assignee: | Scheme Project <scheme> |
Status: | RESOLVED REMIND | ||
Severity: | normal | CC: | bradmwalker, plh, seemant |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
slib-3.1.1.ebuild (proposal1)
dev-scheme/slib/slib-3.1.4.ebuild dev-scheme/slib/slib-3.1.4.ebuild dev-scheme/slib/slib-3.1.4.ebuild |
Description
Bardur Arantsson
2004-03-26 11:34:32 UTC
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]
slib-3.1.1.ebuild (proposal1)
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 * app-office/gnucash-1.8.11 description: A personal finance manager homepage: http://www.gnucash.org/ * app-office/gnucash-2.0.1 description: A personal finance manager. homepage: http://www.gnucash.org/ * dev-libs/g-wrap-1.3.4-r1 description: A tool for exporting C libraries into Scheme homepage: http://www.gnucash.org (In reply to comment #5) A better one :) # pquery --raw --revdep dev-libs/slib app-office/gnucash-1.8.11 app-office/gnucash-1.8.12 app-office/gnucash-2.0.1 app-office/gnucash-2.0.2 dev-libs/g-wrap-1.3.4-r1 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]
dev-scheme/slib/slib-3.1.4.ebuild
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]
dev-scheme/slib/slib-3.1.4.ebuild
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]
dev-scheme/slib/slib-3.1.4.ebuild
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: > 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. (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> (version) "1.8.1" guile> (use-modules (ice-9 slib)) ;; before ice-9/slib.scm workaround ERROR: Unbound variable: slib:features ABORT: (unbound-variable) 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 Backtrace: 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 ABORT: (unbound-variable) guile> (require 'srfi-94) ;; load real-exp, real-ln guile> (real-exp 1) 2.71828182845905 guile> (real-ln (real-exp 1)) 1.0 guile> 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. |