Re: A couple of things that I think should be in byte bytecode meta comments

[Rocky Bernstein]

On Fri, Dec 22, 2017 at 3:25 PM, Eli Zaretskii <address@hidden> wrote:

> From: Rocky Bernstein <address@hidden>
> Date: Fri, 22 Dec 2017 13:49:06 -0500
> Cc: address@hidden
>
> 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.