Bugzilla Bug 66135

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 an attachment (id=40922) [details]
Updated ebuild for new 5.9.1 maxima release

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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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.