On Fri, Dec 22, 2017 at 3:25 PM, Eli Zaretskii wrote: > > From: Rocky Bernstein > > Date: Fri, 22 Dec 2017 13:49:06 -0500 > > Cc: emacs-devel@gnu.org > > > > Now as to the portability. Yes, if the file is run on another system, > the path isn't exact. But it does give some > > idea of what we are talking as you git closer to the bottom of the path > and that may be helpful. > > > > Consider cases where I have a stable and development branch and then > install into say > > /usr/local/share/emacs/lisp. Even though the top-level directories are > not the same, it still is useful to know > > where in the source code tree (whether on my system or not). > > I guess I'm not following you. On my system, there are 60 files whose > absolute file names end in lisp/emacs-lisp/bytecomp.el. (And my > equivalent of your /usr/local/share/emacs is populated with files that > came from a tree which is not the stable nor the development branches.) > Some of these 60 files come from the same versions of Emacs, some from > different versions. How can a signature that records the absolute > file name help in distinguishing between bytecomp.elc's that were > produced from the same or identical files, and those which were > produced from different, i.e. "incompatible" files? What am I missing > here? > That there is also a SHA of the text. If the text in any of those 60 files is identical it doesn't matter for purposes of debugging and error location determination which one in the set you decide to call the source. > > And finally there will be cases where the path is exact. > > Too few to rely on, what with today's practice of installing pre-built > packages instead of building from sources on each end-user system. > > > In sum, just because sometimes it doesn't work out, doesn't mean it will > be totally meaningless all the time. > > And I prefer "sometimes useful" to no information, however accurate that > is. > > I'm saying that the minuscule amount of times it will work will drown > in the sea of times it won't. Worse, when it "doesn't work", it will > many times produce a false alarm: the file name is different, but the > contents was identical. If that's the case, then how is this different than what we have now? How will you distinguish between true > negatives and false negatives? Without a means to distinguish between > them, this feature will be worse then useless: it will be an absolute > nuisance. > Again, the SHA.