# Copyright 1999-2003 Gentoo Technologies, Inc. # Distributed under the terms of the GNU General Public License v2 # $Header: $ DESCRIPTION="Free computer algebra environment, based on Macsyma" HOMEPAGE="http://maxima.sourceforge.net/" SRC_URI="http://dl.sourceforge.net/sourceforge/maxima/maxima-${PV}.tar.gz" LICENSE="GPL-2" SLOT="0" KEYWORDS="x86 ~ppc ~sparc ~sparc64 ~alpha" USE="" DEPEND=">=dev-lisp/clisp-2.29 >=sys-apps/texinfo-4.3" RDEPEND=">=dev-lang/tk-8.3.3" S=${WORKDIR}/${P} src_compile() { econf emake || die } src_install() { make DESTDIR=${D} install || die }
This is for Maxima version 5.9.0 The ebuild should be named: "app-sci/maxima" Sorry for not providing these specifics with the original submission. -- Sourav
Hmm. I shouldn't really talk, since I don't know quite how to proceed with this, but a "proper" maxima ebuild would have quite a few more options, and perhaps even need some more use flags. I just don't know. There are lots of optional features which are very nice to build but have more requirements: Tcl/Tk is needed to build xmaxima emacs is needed for maxima mode there is a latex enabled mode called emaxima that needs tetex as well as emacs building on multiple lisps is possible - gcl, cmucl, and clisp currently. This is where use flags might be needed - the idea would be to require at least one of the three, but build against as many of these three as are available on the system. Probably other minor issues will crop up, but the big question is: is there any way all this could be done with an ebuild? If there are emacs and tex use variables they could serve for maxima mode and emaxima, but currently I can't see any way around adding gcl, cmucl, and clisp to the use flag selection, which probably wouldn't make the gentoo developers very happy? Other packages might be able to make use of such flags in the future, but I just don't know.
To address your comments: * Tcl/Tk: It's a runtime dependency, not a build-time dependency; this is already included. * emacs/latex hooks: I did not know these existed! Certainly, the configure script has no special facilities for them. If they are indeed included in the distro, the ebuild would have to do some special post-install things to make them usable. * various lisps: The configure script does allow for different lisp interpreters. I tried it with gcl and clisp, and only got it to finish the build with clisp, so that's what I chose. Yeah, adjusting this "properly" would require a USE variable, which adds bloat to Portage. In any case, I use MuPAD now, which is free for non-commercial use. :-P
I'm very interested in this ebuild for maxima. I want to ask how soon it will be implemented into the portage tree or if not, if this listed one is useable. Or do you need some testing?
Hi guys. Harald: on how soon part: its pretty standard, when I'll get to it going through my list of bugs ;). Which actually looks to be pretty soon, its almost the next one. Testing would definitely be welcome, but since I am going to go through it in a few days, could you please hold-off until I process it and include in the tree. I would appreciate your testing a lot at that point. George PS, if you want to receive notification emails, its good to add yourself to CC on the bug ;).
Oh, when I added my email to the CC list, it sent emails to everyone of you (my first time on bugzilla :). So, I thought I rather express my interest in maxima ebuild...Anyway, when I tried to install maxima using source, I found that the gcl (2.4.0) did not include some of the files necessary for maxima (a bad ebuild?). I downloaded the latest gcl and the files it was asking were there...I hope this has already been figured out so I haven't included all the details. I am looking forward to testing the ebuild pretty soon.
Hello, original sumbitter here. If you are eager to test the package, please download the ebuild and put it in your overlay tree. You could play with it until George gets to it, and perhaps submit enhancement. I could only get maxima to work with CLISP; if you can get it to build with gcl, feel free to tweak the ebuild.
I downloaded the gcl version 2.5.2 and tried to compile it, but it won't compile at all. Then I tried to report the bug at gcl website but it won't let me open an account to report it! Looks like its still a long way to get maxima working even without an ebuild. asubedi
I have also had problems building gcl 2.5.2 on gentoo. I have reported these problems to the list, and we will see what happens, but the main developer is gone for a while and nothing will likely happen anytime soon. I think the build system for gcl is showing its age and the new tools/libs on gentoo break stuff. I did get gcl to build on my system once a while back from a cvs version, but I think between their updates and mine there's not much chance of that working again. My take on this is a) we don't actually NEED gcl to run maxima, so it's not terribly urgent (although it would be nice) and b) we should offer the option to build off of both clisp and the latest cmucl, 18e I think. This is a vast improvement over earlier cmucl lisp versions IMHO. It still doesn't have readline, but it should offer speed advantages. I haven't looked at the cmucl ebuilds lately to see if there is an 18e one in there - has anyone added one? Also, is there any way to create a source package of cmucl, using the cmucl binary as a boot strap mechanism? I don't know of any way to do this other than use flags - does anyone know of a good way? Also, about the emacs/latex stuff - I'd really recommend installing that using postinstall or whatever - it's good stuff. The key things are - *el files need to be in the load path for emacs, the .sty file needs to be in /usr/share/texmf/tex/latex/<some folder> - on my machine I put it in /usr/share/texmf/tex/latex/emaxima/ pdfcolmk.sty also needs to be present on the system - does gentoo's tetex install include that file by default now? If not that file should be added. Also, for emaxima to function at full potential it needs auctex. This is a quirk I notice in portage - when I say emerge --pretend auctex it gives me the xemacs version. I do have xemacs installed, but I ususally use emacs - how do I specify the auctex package for emacs rather than xemacs? The correct ebuilds are present in /usr/portage/app-emacs/auctex/ IIRC, by default the install puts the emacs files and emaxima.sty in /usr/share/maxima/5.9.0/emacs/ The other thing that needs to happen to make everything work is that certain key entries have to be placed in the users .emacs file. I don't know if there is a system equalivent where these could be defined for all users. I think the required/desirable commands are: (warning - this is off my own system which has all sorts of custom non ebuild stuff related to maxima everywhere, so this may or may not work on a default ebuild setup. Also, the first command is only needed if the el files aren't copied to /usr/share/emacs/site-lisp - I'd recommend they stay put actually, since if they do it is possible to cleanly install multiple versions of maxima at once.) (setq load-path (cons "/usr/share/maxima/5.9.0/emacs" load-path)) (autoload 'maxima-mode "maxima" "Maxima mode" t) (autoload 'maxima "maxima" "Maxima interaction" t)(autoload 'maxima "maxima" "Maxima" t) (setq auto-mode-alist (cons '("\\.max" . maxima-mode) auto-mode-alist)) (autoload 'emaxima-mode "emaxima" "EMaxima" t) (add-hook 'emaxima-mode-hook 'emaxima-mark-file-as-emaxima)
Hi guys. Glad to see such activity on this one :). asubedi, Cliff: you say you have trouble emerging gcl? I think a bug is in order then ;), I did not find any open bugs related to gcl.. On the building maxima off various lisps: what are the differences in the result wrt clisp vs cmucl? Is that a speed versus stability and compatibility tradeoff? (Could you please give some more details?) In such case I agree that we should present users with the choice. If the result is virtually indistinguishable, I don't see the point in making ebuild more complex than it needs to be.. >Also, is there any way to create a source package of cmucl, >using the cmucl binary as a boot strap mechanism? Sure, please take a look at dev-lang/ghc for example. Note, that it is not necessary to create two packages (a separate -bin one) in general, the bootstrapping can be done easily all within the ebuid (take a look at the earlier versions). For ghc it was done mostly because the build is quite involved and could easily take many hours on a decent hardware. As for the lisp selection. This can be easily done via local USE flag (a unique flag, that does not have to be registered in use.desc, it gets registered in use.local.desc instead). The dependency may be specified in the form: DEPEND="|| ( cmucl? ( dev-lisp/cmucl-bin ) dev-lisp/clisp )" Cliff: I see you have spent quite some time working with maxima and various lisps. Mind implementing the suggested improvements? ;) Do not hesitate to ask me if you have any problems. Ok, back to the original issue. I have processed and committed the ebuild. Please test. Please note, that I had to do some adjustments - I added the AECA (Export Conrol Act) to the pool of our licenses and adjusted LICENSE field accordingly. Also the USE="" line should have been IUSE="" ;). Please use the committed ebuild as a base of any future modifications ;). I will leave this bug open meanwhile, since it looks like more may be coming.. George PS BTW, just recently I processed "Yet Another Computer Algebra System", #3790. Everybody interested is wellcome to take a look and test :).
Forgot to ask. Sourav: I see you populated KEYWORDS with ~'s for every arch you could find. Does that mean, that the package has been tested to work on all these arches or at least to believe, that it would? George
> asubedi, Cliff: you say you have trouble emerging gcl? I think a bug is in > order then ;), I did not find any open bugs related to gcl.. Well... It's more a case of gcl isn't ready to build on gentoo yet, I think. It's not a fault of the ebuilds really, although once a working gcl emerges the old ones should probably be removed. > On the building maxima off various lisps: what are the differences in the > result wrt clisp vs cmucl? Is that a speed versus stability and compatibility > tradeoff? (Could you please give some more details?) Sure. As a general rule of thumb, cmucl is considerably faster than clisp. IIRC this has to do with how cmucl and clisp compile their code - clisp is designed to be more portable, and that has some impact on speed. Clisp, however, has many more goodies than cmucl, including readline support. cmucl lacks readline and that makes Maxima in it almost unusable on the straight terminal command line. My own default lisp is cmucl, because I tend to prefer working in Emacs mode. But for command line users lisp is currently a lot more friendly. I don't know if I made this clear, but the way maxima works now it is quite possible for the same build process to create different images for clisp, cmucl and gcl. Install will then install all the images, and the maxima command accepts arguments at run time, so the user can select on a per session basis which underlying lisp they want to run on. As a philosophical issue, I would like to see the ebuild support as many lisps as possible, to allow maximum choice to the user. My feeling is the following would be the best way to go at some point in the future: Default build on clisp - friendly, readline supported Maxima. If no lisp use variables are set, use clisp. Then allow use variables for building on additional lisps, such as cmucl and gcl (sbcl support is also present in the cvs version - that will be a 5.9.1 feature. acl will be supported as well, but I don't think there is an ebuild for acl since it's commercial) > In such case I agree that we should present users with the choice. > If the result is virtually indistinguishable, I don't see the point in > making ebuild more complex than it needs to be.. Basically to allow an advanced user to tweak all the Maxima build options without having to do a custom job of it. The maxima configure script makes building on multiple lisps easy - if the ebuild doesn't support that the advanced users will just build themselves, and miss out on using portage to track it. Of course cmucl and clisp are sufficiently different to justify it anyway, but one of the things I like about gentoo is the choice and control it gives you. I've installed a fair number of science related programs on gentoo without ebuilds, because I'm not very good at writing them or could only get the binaries to work. But I do miss the portage features. On a quasi related note, the scilab build stands at 2.6 - I just updated the version number without changing anything else in the ebuild and I got 2.7 to compile and run. Haven't tested it thoroughly though. >>Also, is there any way to create a source package of cmucl, >>using the cmucl binary as a boot strap mechanism? > Sure, please take a look at dev-lang/ghc for example. Note, that it is not > necessary to create two packages (a separate -bin one) in general, the > bootstrapping can be done easily all within the ebuid (take a look at the > earlier versions). For ghc it was done mostly because the build is quite > involved and could easily take many hours on a decent hardware. Ah. I expect cmucl would be similar. Now if I could only figure out how to build it ;-). That's actually what sbcl brings to the table - cmucl like performance and an understandable build system. > As for the lisp selection. This can be easily done via local USE flag (a > unique flag, that does not have to be registered in use.desc, it gets > registered in use.local.desc instead). The dependency may be specified in the > form: > DEPEND="|| ( > cmucl? ( dev-lisp/cmucl-bin ) > dev-lisp/clisp > )" OH. OK. That's a good idea. > Cliff: I see you have spent quite some time working with maxima and various > lisps. Mind implementing the suggested improvements? ;) Well, we'll see if I can figure out how. > Do not hesitate to ask me if you have any problems. Brace yourself ;-). > Ok, back to the original issue. > I have processed and committed the ebuild. Please test. > Please note, that I had to do some adjustments - I added the AECA (Export > Conrol Act) to the pool of our licenses and adjusted LICENSE field > accordingly. Also the USE="" line should have been IUSE="" ;). Please use the > committed ebuild as a base of any future modifications ;). OK. > I will leave this bug open meanwhile, since it looks like more may be coming.. We'll see... > PS > BTW, just recently I processed "Yet Another Computer Algebra System", #3790. > Everybody interested is wellcome to take a look and test :). Sounds good. Always glad to see more sci/math apps in gentoo. CY
> Forgot to ask. > Sourav: I see you populated KEYWORDS with ~'s for every arch you could find. > Does that mean, that the package has been tested to work on all these arches > or at least to believe, that it would? Maxima, at least in command line form, should be almost as portable as the lisp it runs on. I believe the Debian Linux package tested out on all their archs. The graphics may be a bit more picky - it's hard to say. I wouldn't expect them to be. But the command line version has run on everything from PDPs to Windows over the years. If there are problems on gentoo platforms, we'd be interested to hear about it. Although likely as not the underlying lisp might be the problem - sometimes handling things like numbers across platforms is rather difficult.
>>I will leave this bug open... Ah, here it is, but it seems like the fault of xmaxima rather than the ebuild as I encountered this problem yesterday when I had built it from source by myself. Anyway, when I start xmaxima, the user interface pops up but i cannot execute any expression. After sometime it says "Starting maxima timed out. Wait longer?" and in the command prompt i have: (C1) *** - UNIX error 22 (EINVAL): Invalid argument The following restarts are available: R1 = Macsyma top-level 1. Break [1]> I can work in the command line and plot 3d graphs, too. However, I have not been able to work in emacs.
> Forgot to ask. > Sourav: I see you populated KEYWORDS with ~'s for every arch you could find. > Does that mean, that the package has been tested to work on all these arches > or at least to believe, that it would? Yes, I believed that it would be quite portable since it's an end-user app with very basic hardware/X interaction. We'll see if I was too naive ...
Hmm. Please submit this bug to the Maxima list. What platform are you on, and what version of clisp are you using? (C1) *** - UNIX error 22 (EINVAL): Invalid argument The following restarts are available: R1 = Macsyma top-level 1. Break [1]>
Well, I apparently suck at ebuild script creation. I tried the ebuild below, and it apparently ignores all my configure settings. Help? (WARNING - the below ebuild is NOT a working ebuild. Most of the fancy tex and emacs stuff is almost certainly wrong.) # Copyright 1999-2003 Gentoo Technologies, Inc. # Distributed under the terms of the GNU General Public License v2 # $Header: /home/cvsroot/gentoo-x86/app-sci/maxima/maxima-5.9.0.ebuild,v 1.1 2003/04/19 08:59:47 george Exp $ DESCRIPTION="Free computer algebra environment, based on Macsyma" HOMEPAGE="http://maxima.sourceforge.net/" SRC_URI="http://dl.sourceforge.net/sourceforge/maxima/maxima-${PV}.tar.gz" LICENSE="GPL-2 AECA" SLOT="0" KEYWORDS="~x86 ~ppc ~sparc ~sparc64 ~alpha" IUSE="tetex emacs auctex" DEPEND="|| ( cmucl? ( dev-lisp/cmucl-bin ) tetex? ( app-text/tetex ) emacs? ( app-editors/emacs ) auctex? ( app-emacs/auctex ) dev-lisp/clisp-2.29 >=sys-apps/texinfo-4.3") RDEPEND=">=dev-lang/tk-8.3.3" S=${WORKDIR}/${P} src_compile() { local myconf="--enable-clisp" use cmucl && myconf="${myconf} --enable-cmucl" ./configure --prefix=/usr ${myconf} || die emake || die } src_install() { make DESTDIR=${D} install || die if [ -n "`use emacs`" ] then elisp-install ${S}/interfaces/emacs/emaxima *.el *.elc insinto /usr/share/emacs/site-lisp doins ${S}/interfaces/emacs/emaxima/emaxima.lisp fi if [ -n "`use tetex`" ] then insinto /usr/share/texmf/tex/latex/emaxima doins ${S}/interfaces/emacs/emaxima/emaxima.sty fi #move docs to the appropriate place dodoc AUTHORS ChangeLog COPYING COPYING1 NEWS README* mv ${D}/usr/share/${PN}/${PV}/doc/* ${D}/usr/share/doc/${PF}/ } pkg_postinst() { if [ -n "`use emacs`" ] then einfo "Running elisp-site-regen...." elisp-site-regen fi if [ -n "`use tetex`" ] then einfo "Running mktexlsr to rebuild ls-R database...." mktexlsr fi if [ -n "`use emacs`" ] then einfo "In order to use Maxima with emacs, add the following to your .emacs file: (setq load-path (cons "/usr/share/maxima/5.9.0/emacs" load-path)) (autoload 'maxima-mode "maxima" "Maxima mode" t) (autoload 'maxima "maxima" "Maxima interactive" t) (setq auto-mode-alist (cons '("\\.max" . maxima-mode) auto-mode-alist)) (autoload 'emaxima-mode "emaxima" "EMaxima" t) (add-hook 'emaxima-mode-hook 'emaxima-mark-file-as-emaxima)" fi }
> src_compile() { > > local myconf="--enable-clisp" > use cmucl && myconf="${myconf} --enable-cmucl" > ./configure --prefix=/usr ${myconf} || die > emake || die >} Are you sure it shouldn't read: ------- src_compile() { local myconf="" if [ -n "$(use cmucl)" ]; then myconf="${myconf} --enable-cmucl" else myconf="${myconf} --enable-clisp" fi ./configure --prefix=/usr ${myconf} || die emake || die } ---------- I'm guessing that the "configure" script still uses clisp cuz it's seeing "--enable-clisp --enable-cmucl"; for cmucl to work using your logic, "$myconf" must read "--enable-clisp --disable-clisp --enable-cmucl" or some such. What else isn't working?
> Are you sure it shouldn't read: [snip] Yes I'm sure it shouldn't be that - my build isn't starting out with clisp. It's starting out with gcl, which the ebuild script doesn't even know exists. > I'm guessing that the "configure" script still uses clisp cuz it's seeing > "--enable-clisp > --enable-cmucl"; for cmucl to work using your logic, "$myconf" must read > "--enable-clisp > --disable-clisp --enable-cmucl" or some such. No no. I don't want to disable clisp - I want to enable BOTH clisp AND cmucl. I think you're thinking about how Maxima builds this incorrectly. Here's what actually happens. Maxima is a lisp program - in order to compile it you have a lisp implimentation - clisp, cmucl or gcl in the case of the current release - load all the source code, compile it, and then save the whole thing as a lisp image. The build system can handle creating lisp images on multiple lisps in the same build process. Say, for example, I compile with the following options: ./configure --enable-gcl --enable-clisp --enable-cmucl make Make will build the entire Maxima system using gcl, clisp and cmucl, creating three lisp image files. Then make install installs each image into its own directory. The script named /usr/bin/maxima then accepts an option which allows you to select which lisp image you want to use - gcl, clisp or cmucl. So you build all of them in advance, and then you can select at runtime which one to use. That way, if you have a new user on your system you can start up with clisp but if you want to do some heavy number crunching you can start up with cmucl. All by using a toggle at runtime, and the compiled image is available for each lisp implimentation. > What else isn't working? Don't know. Haven't gotten to first base, so I haven't found out what (if anything) is wrong with the rest. But I'm sure something is - it's completely untested.
>>Hmm. Please submit this bug to the Maxima list. What platform are you on, and what version of clisp are you using? $ clisp --version GNU CLISP 2.30 (released 2002-09-15) (built 3259773810) (memory 3259774028) The xmaxima is not working when I installed it using ebuild and it was not also working when I had compiled it by myself. I have submitted this bug at maxima's sf website.
as wished, i tested the current ebuild (maxima-5.9.0.ebuild,v 1.2 2003/04/19 20:16:51) and well, it installed clisp and works (calculation and plotting pretty fine, ui could be better...but thats not gentoos business ;) but there is at least one problem, there is no help!! are help files separeted or is there a path problem?
I know that the docs should take place under /usr/share/doc, but that is not where xmaxima will be looking for them... So leaving them under /usr/share/${PN}/${PV}/doc/* is much better... I just commented out that last line of src_install() and xmaxima now words fine. (It didn't work at all previously !) Perhaps a symbolic link to the docs might be done on /usr/share/doc/maxima-... ? Thanks anyway for this ebuild. (Not yet perfect, but it works) btw maxima+texmacs is superb
Sorry, forgot to add my email to follow this bug
Hi guys. Sorry for a rather long delay. Looks like most of the activity felt on this bug when bugzilla had some notification problems and I did not get proper notifications in time :(. Anyway, I have composed something out of Cliff' and Sourav's additions, which is committed now as the -r1.ebuild. Please test it. Also I marked the -r0 one (plain 5.9.0.ebuild) as stable, as it seemed to perform well for what it was designed to do. Oh, the new ebuild has all four use flags (although I adjusted DEPEND to actually do what we intended it for ;)) and naturally I added two of the to use.local.desc. Cliff: it is really really much better to *attach* stuff (especially ebuilds) to the bug, instead of posting them in. Saves quite a bit of clean-up work and prevents some copy-paste breakage.. There is no new version, and with this one committed looks like this is it for now. Marking this bug TEST-REQUEST then :). George
> Sorry for a rather long delay. Looks like most of the activity felt > on this bug when bugzilla had some notification problems and I did > not get proper notifications in time :(. Figures. No problem. > Anyway, I have composed something out of Cliff' and Sourav's > additions, which is committed now as the -r1.ebuild. Please > test it. Can you please upload it as an attachment? My gentoo machine is off the net at the moment and I can't seem to find the new one in the cvs interface. > Also I marked the -r0 one (plain 5.9.0.ebuild) as stable, as it > seemed to perform well for what it was designed to do. Sounds good. > Oh, the new ebuild has all four use flags (although I adjusted > DEPEND to actually do what we intended it for ;)) I figured I messed something up. Did my post install stuff for the emacs modes make any sense? There seemed to be some stuff in the ebuild system for handling such things, but I couldn't really make much sense of it. > and naturally I added two of the to use.local.desc. OK. Would people wanting to install Maxima need to do that as well? > Cliff: it is really really much better to *attach* stuff > (especially ebuilds) to the bug, instead of posting them in. > Saves quite a bit of clean-up work and prevents > some copy-paste breakage.. Opps. Sorry. I didn't think anyone would want to download my first attempt, since the odds against it working were rather significant. The original plan was for someone to laugh at me, tell me what I was doing wrong, and then I would post a working one. I'll try to default to using the attachment method instead. (P.S. - why does cut and paste not work, by the way? Is portage fragile about whitespaces?) > There is no new version, and with this one committed looks > like this is it for now. Marking this bug TEST-REQUEST then :). Cool. I'll try to give it a shot, but it may not happen until my gentoo box is back on the net (just moved.) CY
> Can you please upload it as an attachment? My gentoo machine > is off the net at the moment and I can't seem to find the new > one in the cvs interface. Never mind, I found it on one of the mirrors. One major problem: the way Sourav suggested handling the clisp/cmucl issue doesn't result in lisp images being build on both clisp and cmucl if both USE flags are set. The desired behavior is to have both --enable-clisp and --enable-cmucl in the configure script if both USE flags are present - it's not an either/or situation. The desired behavior would be: USE="" -> ./configure --enable-clisp USE="clisp" -> ./configure --enable-clisp USE="cmucl" -> ./configure --enable-cmucl USE="clisp cmucl" -> ./configure --enable-clisp --enable-cmucl In the latter case, the maxima build system builds BOTH images and installs them. Then, at run time, a maxima user can decide to run on cmucl or clisp on a per start basis, by doing something like: maxima -l clisp maxima -l cmucl Also, the build can also handle gcl, which can be added since gentoo now has a working gcl ebuild (I didn't add it because I was building on it initially even without the ebuild knowing about it, which was bad.) CY
Created attachment 15680 [details] Try at an ebuild with gcl and full simultaneous lisp building Totally untested.
Created attachment 15681 [details] Attempt at updated ebuild
Grr. OK, ignore the second attachment and look at the first. It is flawed because it doesn't request the clisp dependancy in the absence of the clisp flag if none of the lisp flags are used, but other than that it's the general idea. Perhaps something like DEPEND="( clisp? ( dev-lisp/clisp ) cmucl? ( dev-lisp/cmucl ) gcl? ( dev-lisp/gcl ) dev-lisp/clisp ) cmucl? ( dev-lisp/cmucl-bin ) clisp? ( dev-lisp/clisp ) gcl? ( dev-lisp/gcl ) tetex? ( app-text/tetex ) emacs? ( app-editors/emacs ) auctex? ( app-emacs/auctex ) >=sys-apps/texinfo-4.3 >=sys-apps/clisp-2.29 >=sys-apps/cmucl-bin-18e >=sys-apps/gcl-2.5.3" would work? (A somewhat similar syntax is in the initial r1 ebuild, but I don't fully understand it so I probably did that wrong.)
Dude, you're moving the docs again -- can't do that, as the xmaxima help facility expects the doc tree to be in a certain place. It's safe to move the GNU standard files (README, ChangeLog, etc.).
Whoa, took some tweaking, but finally I got dependencies the right way! Please check new version of the -r1 ebuild. No revision bump, since it had (still has, more below) some problems with clisp - I don't think many people got it installed. On a related note, Sourav, Cliff: could you please take a look at #27397? Looks like clisp support is problemmatic. Apparently this bug is triggered by --enable-clisp switch. George
> Whoa, took some tweaking, but finally I > got dependencies the right way! Very impressive! > Please check new version of the -r1 ebuild. No revision > bump, since it had (still has, more below) some problems > with clisp - I don't think many people got it installed. Hmm. What's the default clisp version in gentoo now? I can't test in a big hurry, since my monitor died :-(. I'll try to look at it once I get a new one, but that could be a while. Major concern - I see the docs being moved - are they moved to the place where xmaxima is looking for them? > On a related note, Sourav, Cliff: could you please > take a look at #27397? Looks like clisp support is > problemmatic. Apparently this bug is triggered by > --enable-clisp switch. That's surprising. I'm not sure what that specific error means. Which version of clisp is being used? Also, does this happen if clisp and maxima are built outside the ebuild system? Maybe there are some flags it can't tolerate.
Xmaxima seems able to find the docs just fine -- good work!
Thanks for testing! Closing the bug now (or reclosing, I think it was reopened by the latest change to bugzilla) George
