emacs ebuild should install a symlink from /usr/shame/emacs/site-lisp/ to /usr/shame/emacs/site-lisp/lisp since this fixes a bunch of problems with jde and possibly other emacs extensions where they look for a "lisp" directory which doesn't exist...
Steps to Reproduce:
1. install emacs
2. install jde
3. try to run (inside emacs) jde-compile-jde
you get an error saying it cant find /usr/shame/emacs/site-lisp/lisp
it should compile jde
it seems that if you just make a symlink pointing /usr/shame/emacs/site-lisp/lisp back to /usr/shame/emacs/site-lisp/ it fixes the problem.
Adding such a symlink would be a workaround only. The real problem is with JDEE and should be fixed there.
What versions of emacs and app-emacs/jde are you using?
Ok, this fixed a couple different bugs actually with jde, and seems like it would just provide compatibility with other distributions emacs deployments, but feel free to pass it along to the jde team. I run app-emacs/jde-2.3.6_pre20081208. The problem hit me when I was running app-editors/emacs-22.3-r2 but I now run
app-editors/emacs-23.1, with the symlink still there, and it seems to work well that way.
Now I remember again: When preparing jde-2.3.6_pre20081208-fix-paths-gentoo.patch for bug 259933, I came across jde-compile-jde and jde-autoload-update and decided that these functions would not be needed, because any files under /usr/share/emacs/site-lisp/ are part of the installed system and should not be modified by users.
So I tend to close this bug report as invalid. But maybe your usage case is valid? Could you please elaborate on it?
Ok, that makes sense. The symlonk fixed jde-create-project for me too though, and that's definitely an important one. The reason I was trying to run jde-compile-jde was actually to try to fix that one. Thanks again for looking into it.
(In reply to comment #4)
> The symlonk fixed jde-create-project for me too though, [...]
That's function jde-project-create-project?
jde-create-new-project. On further analysis, the symlink by itself didn't fix it, but making the symlink and then running jde-compile-jde fixed it.
Closing, since we won't add the symlink.
Feel free to file a separate bug for the jde-create-new-project issue (which so far I cannot reproduce).
Ok, I'll accept that the jde-create-new-project issue could possibly (though it seems rather strange to me), be some isolated quirk of my own system, but deliberately breaking your software to disable features you don't want users to mess with (even when they mmight need those features to potentially fix other problems with your software) seems like a pretty terrible way to go about things. Not my call though, and thanks anyway for looking into it, I do appreciate the time spent. Ciao.
(In reply to comment #8)
> deliberately breaking your software to disable features you don't want users
> to mess with (even when they mmight need those features to potentially fix
> other problems with your software) seems like a pretty terrible way to go
> about things.
We don't "deliberately break" anything. jde-compile-jde and jde-autoload-update are as provided from upstream. But as I've said above, they don't make much sense on a Gentoo system. A normal user won't even have write access to the lisp directory. So the decision was not to spend any effort to fix the broken functions.
A huge problem with JDE is that it contains hardcoded path names all over the place, which are neither configurable at build time nor at run time. Look at the ebuild and the patchset of 2.3.6_pre* and you'll see what I mean.