This is an updated ebuild for the new Maxima 5.9.1 release. It adds support for sbcl, warns about potential gcl issues, checks for current lisp distributions, and hopefully should work without any trouble with the current available ebuilds for the various lisps in question. With any luck, the new 5.9.1 release will resolve problems people have been encountering building Maxima. Reproducible: Always Steps to Reproduce:
Created attachment 40922 [details] Updated ebuild for 5.9.1 (use ebuild below rather than this one)
Nick Savchenko provied a fix for the .emacs information which is valid for this case too - with thanks to him for spotting it, applied fix to 5.9.1 ebuild as well.
Created attachment 40951 [details] Fixed the inclusion of quotes in informational messages
Hmm - on my machine I'm seeing emacs * Running elisp-site-regen.... /usr/portage/app-sci/maxima/maxima-5.9.1.ebuild: line 86: elisp-site-regen: command not found I've never really been up on the installing of emacs components - can someone with more experience here tell me what needs doing for that part of the ebuild?
The ebuild needs a line: 'inherit elisp' - but the elisp-site-regen doesn't seem to actually do anything useful for the maxima installation and you still have to follow the instructions for modifying ~/.emacs anyway.
OK. So I should create some kind of maxima .el file to include with the ebuild, and tell people how to load that?
The maxima.el file is already installed into the emacs site-lisp directory and information on how to load it is printed by emerge (thanks to the einfo statements in the ebuild). That's okay but it would be nice if the emerge would automatically put the necessary loading commands into the site-gentoo.el file (?) (same goes for pari-gp, lush and other emacs enabled packages), but I'm not sure how the portage elisp installation mechanism works. I'll be looking into this, probably later today, and I'll post a patch for the ebuild if you don't do so first.
It doesn't go to the emacs site-lisp directory; emaxima.lisp does (I don't know why - it already exists in /usr/share/maxima/.../emacs/ and when I removed it from site-lisp there were no ill effects) but anyway: To put the loading commands into the site-gentoo.el file, all that is needed is a file named eg. 50-maxima-gentoo.el containing the loading commands that the einfo statements print to be installed into the site-lisp directory along with (instead of) emaxima.lisp. The elisp-site-regen will then copy the contents of that file into site-gentoo.el.
Created attachment 41153 [details] Archive of new ebuild and site-lisp file for maxima. On closer inspection, it appears that the original ebuild was putting a tree of spurious directories in the emacs site-lisp directory (as well as the unnecessary .lisp file) - see /usr/share/emacs/site-lisp/var/ - so I've cleaned that stuff out and made the requisite 50maxima-gentoo.el file. It has built properly with gcl on my system and now ~/.emacs only needs to contains the line: '(load "/usr/share/emacs/site-lisp/site-gentoo")' or similar (emerge prints a message about this at the end of the build).
Ebuild in comment #9 works for me (including both maxima and maxima-mode in GNU Emacs). Next time just attach both files instead of a tarball please.
Heh - I should check back more often. I just got done putting together almost the exact same set of changes. Yours look slightly better though - you spotted the copying to /usr/share/emacs/site-lisp isn't needed, which I missed. For me at least, that clears up the last known headache associated with this ebuild. Thanks for some excellent work. <evil grin> Maybe I can finally start to hand off my .emacs file to gentoo, if octave, pari, etc. also do this. Right now I've got Maxima, Octave, Yacas, Gri, gnuplot, Macaulay2, HOL, and SLIME configs in my .emacs file. HOL I don't think is in portage, but I think most or all of the rest are.
Sorry about the tarball Colin and thank you Cliff for the 5.9.1 ebuild in the first place. The elisp.eclass mechanism is a good one and I too hope that maxima and the other packages are modified to use it. A 5.9.1 maxima ebuild has just appeared in portage but without our fixes, so it's still broken and I didn't even know gnuplot had some emacs stuff (it only has an xemacs USE flag and installed nothing for me) so thanks for mentioning it.
Auugh. I've been waiting for 5.9.1 so we could finally fix all the maxima ebuild issues, and they stick in a broken one? Mumble... Oh, did anybody check that the docs are installed in whatever the "right" place is, and that Maxima is OK with it? I forgot to check that. If that's OK, then I guess Axiom is probably next up, assuming it can actually be built as an ebuild ;-). I usually end up using gnuplot from the command line, but I really need to break that habit and do more work in emacs. I'll take a look at the gnuplot ebuild and see if the emacs stuff can be added easily.
The maxima docs are okay AFAIK. This is a bit off topic but I've already looked at gnuplot and it only installs the emacs stuff if you have set the xemacs USE flag and then you have to install xemacs too. However, if you're running emacs or emacs-cvs you're in luck because you can emerge gnuplot-mode which will install the very same emacs stuff for gnuplot and it does so the right way. :)
Stefan, maybe you should have a look or two at this bug since you did this last version bump.
Created attachment 41317 [details] Couple minor fixes - remove the elisp-regen stuff, add gnuplot as a RDEPEND Couple minor fixes in this one - basically added gnuplot runtime requirement and removed unnecessary elisp regen call. Maintainers - please, please, pretty please use this version instead of just bumping the old 5.9.0 number. For those of us who have tested it this one seems to function MUCH better. If you find more problems we can fix them, but the old ebuild really needs to be retired.
Created attachment 41318 [details] 50maxima-gentoo.el Here's the .el file as its own attachment. The patch file for the 5.9.0 version is still valid in 5.9.1, so it doesn't need to be uploaded here.
Cliff, the elisp-site-regen is not unnecessary! Without it, the site-gentoo.el file does not get updated.
Created attachment 41327 [details] Has gnuplot RDEPEND, add back in elisp-site-regen Fudge. Sorry. I made that one obsolete.
Clearly I'm not at the top of my ebuild game, but I do have a question: Maxima itself is quite able to work with various versions of Maxima installed. Is the SLOT variable designed to support this? The reason I ask is because I would like to create a maxima-cvs ebuild in order to be able to keep up with the development source and at the same time keep an eye on ebuild issues. Installing maxima cvs into /usr/local and playing with PATH works, but makes checking 5.9.1 rather inconvenient. Could SLOT be used to allow simultaneous installation of cvs maxima and 5.9.1?
The SLOT varable was made initally to allow multiple versions of the same library to be installed at the same time (ie. gtk-1.2 and gtk-2.2) Could also be used for programs. It just means that portage does not auto-clean the lesser version number, it will allow one installed version for each different SLOT value. In the case of maxima cvs and 5.9.1, you could just make a new ebuild called maxima-cvs. PS. will get round the updating the ebuild later, good work
Added maxima-5.9.1-r1.ebuild to portage with following changes: Had to remove ppc from KEYWORDS as gnuplot-4.0 is untested there. Changed inherit elisp to inherit elisp-common so emacs is not put in RDEPEND for USE="-emacs". Small white space cleanup (ebuild use tabs not spaces, guess you use emacs to edit) Good ebuild, elisp stuff works a treat.
Just noticed that elisp-common doesn't contain elisp_pkg_postrm() so elisp-site-regen needs to be included in a pkg_postrm() in the ebuild.
Uh - so we need to move the elisp-site-regen command to a new pkg_postrm() section? Or do we need it in two places?
It needs an additional elisp-site-regen in a pkg_postrm() at the end. I found this out when I took a closer look at exactly what is contained in elisp.eclass and elisp-common.eclass after I got the amendment to your imaxima ebuild wrong (btw - hope it works for you now - it's a very nice package but it definitely needs breqn). Going off topic again - I've posted a patch for the gnuplot ebuild to obviate the need for the iffy gnuplot-mode or having gnuplot only work with xemacs. It's in bug #66765 if you'd care to lend some weight to it ;-)
Created attachment 41455 [details] Added postrm section to tidy up emacs files upon removal Is this the right way to do it?
I think so - except I've been wondering whether at uninstall time, ebuilds pick up the USE flags as they were at install time or as they are currently set.
Did a quick check with the USE flags. Seems portage always uses current use flags, not what was set at the time of install. A slight bug/feature in my option. Anyway added the function to the ebuild as it is a marginal problem.
