emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: Re: A couple of things that I think should be in byte bytecode meta comments
Date: Fri, 22 Dec 2017 22:25:22 +0200

> 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?

> 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.  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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]