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

["Drew Adams" <drew.adams@oracle.com>]

> > I have multiple Emacs versions installed (multiple 
> > binaries), and I expect each of them to faithfully have
> > its own set of doc strings, that is, specific to the
> > particular build.  Trying to deal with doc bugs and 
> > improvements would be problematic without this distinction.
> 
> The release version number is coded into the directory name, 
> so it's only different builds of the same release that would 
> have the DOC files winding up in the same directory.  And the 
> build process jumps through some hoops to ensure that the 
> file is consistently built from the same input files, 
> regardless of build options.  And as Stefan has pointed out, 
> there's code to detect when the offsets are wrong (e.g., if 
> functions got added, removed, or reordered).  So if we didn't 
> use filenames varying for each build, the doc strings would 
> actually have to change between builds for the result to be 
> wrong, which I think pretty much confines it to developers' 
> builds.  And even then, it probably doesn't matter much 
> unless the semantics of a function change; having an old 
> binary see typographical or grammatical fixes from a newer 
> build may be less objectionable.
> 
> (The Windows build appears to be different on the naming 
> score, with DOC and DOC-X instead of DOC-nn.nn.nn; I don't 
> know about the other stuff.)
> 
> Still, I'm inclined to think it's better that each version 
> uses the doc strings it was built and installed with.
> 
> Possibly more important is that multiple versions installed 
> under the same prefix with the same release version number 
> will share lisp files, even if the lisp files have changed.  
> So I'm a bit skeptical of the utility of keeping the binaries 
> separate from one install to the next.
> 
> > That concern might be irrelevant to having "a single DOC 
> > file" in the source tree - dunno.  I'm not concerned about
> > the build process, but I would not want multiple binaries
> > of Emacs on my machine to show the same set of doc strings.

Thanks for trying to clarify. My impression from your first paragraph was that
this only affected the build process, not the resulting binaries, so there would
be no problem for users of different binaries seeing the proper doc.

But your last paragraph gives me the opposite impression wrt Lisp code. I admit
I don't really understand.

What I would like is (as now) for each binary (development build) that I use to
have the doc and source code that belongs to it, so I can refer to that doc and
code accurately. If nothing else, that is important for investigating bugs and
filing bug reports.

If that were not the case, it would affect also bug reports that 3rd-party
libraries receive from users of Emacs development versions. Those users need to
have access to the latest (for their build) doc and source code. And so do the
3rd-party developers who try to investigate such bug reports.

Recently I reported an Emacs bug that I narrowed down to changes made between
two particular dates. (Unfortunately, those dates were not close together.) With
the proposed change I might still be able to do that in terms of binary
behavior, but if the source code did not actually differ between the two builds
then I would not be able to use the debugger on the source code or otherwise dig
deeper to find the change that introduced the bug.

I'm guessing that I am just not understanding the issue at all, however. I
cannot imagine that builds would be made available for testing that would not
contain the relevant (up-to-date) doc strings or source code.