Re: [patch] espeak server should not install .so file in /usr/share/emacs

[William Hubbs <w.d.hubbs@xxxxxxxxxxx>]

Hi Tim,

On Tue, Jan 05, 2010 at 05:20:53PM +1100, Tim Cross wrote:
> Possibly the only thing we really need to do is make sure there are no hard
> coded location dependencies in the sources and maybe support a way, such as
> via environment variables or emacs custom variables, which would make it easy
> for package maintainers to put things in their own preferred location. As far
> as I'm aware, I think this is largely already the case.
 
This is true for the most part, but not everywhere, and that is what I
am trying to address with my patches.

look here for example in the espeak server code.  I will make comments
about the concern and point out a better patch than what I did, but, I
don't know enough about tcl myself to do it.

set servers [file dirname $argv0]
set tclTTS $servers/linux-espeak
load $tclTTS/tclespeak.so
# this is a hard coded path that forces the shared library to be in
# ./linux-espeak/tclespeak.so and fails if it isn't there.
# A better approach would be to some how catch this error and try to
# load the shared library from somewhere else, which would be definable
# by the package maintainer.

> Of course the downside of this position is that it may result in fewer distros
> having packaged versions of emacspeak. I'm a little divided on whether this is
> a real issue or not. Emacspeak is a relatively small and easy to install
> application which can run from any installation location. Having to install it
> from svn or a tar snapshot is easy and there is an argument that doing so
> helps users understand how it all fits together and puts them in a better
> position to troubleshoot problems. I also think that the rate at which Raman
> enhances the system is far too high for any packaged versions to keep up, so
> the packaged versions tend to be a fair bit older than the latest stable
> release and a lot older than the current svn version. On the downside, it does
> mean that anyone wanting to use emacspeak will need to be prepared to deal
> with the installation and while not difficult, there are many who are just put
> off by such requirements. Personally, I don't see this as a major issue.
 
 We are almost at a point where we can do both.  As far as I can tell,
 this issue is the only one that needs to be fixed to make both work.

William

Attachment: pgpzfBdtDp8SU.pgp
Description: PGP signature