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

[Ken Raeburn <raeburn@raeburn.org>]

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