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

[Ken Raeburn]

On May 21, 2010, at 20:54, Stefan Monnier wrote:
>>> A simple fix is to get rid of the DOC-NN.NN.NN madness and just use
>>> "DOC" as the file name.  Any objection?
>> Would the emacs-NN.NN.NN madness go with it as well?
> 
> I'd be in favor of it, tho I don't really care.

I thought about that, and was trying to guess what reasons there might be for 
keeping it as is.  All I could come up with was using one emacs binary while 
installing a newly-compiled one into the same tree.  If you change the doc 
strings or order of functions in the emacs C sources, or the pre-loaded Lisp 
sources, the offsets in the DOC file may change, so the values loaded into one 
Emacs binary correspond to its matching DOC file.  (Though there are attempts 
to keep them consistent by running make-docfile on all the stuff you *might* be 
loading depending on the configuration, via ${SOME_MACHINE_OBJECTS}.)

Though, I've also been wondering if it would be worthwhile to compile those doc 
strings into read-only data (shared between processes) in the Emacs binary 
itself, and scrap the DOC file altogether.  Through the wonder of gcc 'section' 
attributes, we could (depending on the configuration) even lump all the 
documentation together on disk pages that don't even need to get loaded unless 
you actually reference them.  Without the emacs/DOC file coordination to worry 
about, simply installing a new binary after deleting the old one or renaming it 
to "emacs.old" should be safer on most systems, even if you're running the old 
one.

Ken