Re: Canonical location for emacs-version string in source tree?

[Ken Raeburn]

On May 24, 2010, at 10:16, Stefan Monnier wrote:
>> Still, I'm inclined to think it's better that each version uses the
>> doc strings it was built and installed with.
> 
> Even tho noone cares that it will still use "the latest .elc file
> around" for the non-prebuilt packages?  And "the docstring from the
> latest .elc file" for non-preloaded packages that have been modified
> and recompiled since you loaded that package?

Well, I think it would make sense for it *all* to stay consistent, once 
installed, or don't even try; the Lisp issue is why I said I'm skeptical of the 
utility of keeping separate binaries.  They get separate doc files but use the 
latest lisp files (and other stuff), and if the old binary is already running, 
or if there were changes in the pre-loaded lisp files, the old binary may run 
into inconsistencies in the interfaces in the Lisp code loaded.  On the other 
hand, if this use case is dependent on stuff not changing much, shouldn't that 
include the DOC file data?

Most other packages I've seen don't make any effort to keep the old installed 
binaries useable after a new installation of the same version (or if they do, 
it's by renaming the old installed binary to "foo.old", not by coming up with 
new names for each new install), and Emacs only does it part-way.  I don't 
think it's worth the effort.  If you really want separately useable versions, 
use --prefix or --program-transform-name or something.  Or we could make Emacs 
figure out where it lives at run time and compute relative paths to the Lisp 
and other support files so the whole tree can be relocated if the developer 
wants to save it, much like Emacs.app on the Mac.

Ken