Re: How does one find out what file a library has been loaded from?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 24 Jul 2022 11:27:56 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > But that is not true.  The original text says something definitive and
> > useful.  Adding information to it should NOT lose any of the
> > information that was there to begin with, because that information
> > still correct and not obsolete.
> 
> I just don't understand you saying that the information is still correct.
> In about "half" the cases, when a .eln file has been loaded, the current
> text in the Elisp manual and load-history doc string is no longer
> correct.  The file given in load-history is not the file that was loaded
> into Emacs.

Natively-compiled Lisp packages are still an exception; people are
definitely less familiar with them than with the byte-compiled ones..
They might not be one day, at which time we might need to change the
text, but for now they are.  So describing the simple case of .elc
first and the more complex .eln case afterwards sounds TRT to me.  As
a nice benefit, it will allow simple and clear description in both
cases, with a simple logic that will not confuse the reader.

> It is proving difficult to amend that text to make it accurate, while not
> confusing its reader.

That's my point: you don't need to amend.  That text is still correct,
as long as no *.eln files are involved.  Just _add_ to it the
description of what happens when *.eln files _are_ around.  This is
good methodology in manuals: describe the simple case first and the
more complex one after it.  Trying to describe both together usually
leads to a much more complex and harder to read text.

If you are still unconvinced, just leave it alone, and I will suggest
the change to that text.

> > Then TRT is to say what happens normally, and then add the description
> > of what happens in exceptional cases, including the description of
> > when the exceptions happen.
> 
> We don't have exceptional cases here.  We have two normal cases, one
> where we load a .elc file, the other where we load a .eln file.  I think
> both somehow have to be described as normal cases.

See above: "normal" and "exception" have slightly different meanings
here.

> One reason not to say it is that we intend the .eln case to become
> the more common case, don't we?

No need to worry about that, not yet.

> Also, we really ought to describe what /home/acm/..../cc-engine.elc
> _is_ in the documentation.  There's no guarantee that that file
> exists.

You are saying that if the .elc file doesn't exist, load-history still
names it and not the .el file instead?  That's not what I see here: I
see the .el files where .elc don't exist.

> All right.  I think it would be useful to tie down the abstraction
> "native compilation unit".  It is probably something quite simple, yet
> there is no "unit" in the Elisp manual index.  What is a "native
> compilation unit"?

Let's get back to that if we decide that the code proposed by Andrea
is really the best solution for this.  If we decide that the best
solution doesn't involve any functions that have "compilation unit" in
their names, we don't need to define that term.

> > > > Did you try comp-el-to-eln-filename?
> 
> > > No.  How could I have known that such a function exists?
> 
> > I just told you about it.  I told you about it not as an accusation,
> > but as a way to help you find the best way of solving your problem.
> 
> OK, thanks.  But I still don't think I could have found out the existence
> of this function without asing "are there any relevant
> functions/variables to what I'm trying to do?".
> 
> > > It generates file names which might not name existing files.  It
> > > doesn't seem ideal for the purpose.
> 
> > Then I think you should describe the purpose better and in more
> > detail.
> 
> I simply wish to know the file from which a function has been loaded, or
> the loaded file corresponding to some source file.  I would like to know
> whether this file is a source file, a .elc, or a .eln.

That is still too general.  I suggest to describe several specific use
cases in more detail, because the solutions might be different.

In general, you can use load-history or symbol-file to know which file
was loaded.  If load-history says it was a .elc file, and the build
supports native compilation, you need to see if the function was
natively-compiled, using

    (subr-native-elisp-p (symbol-function FUNC))

where FUNC is a function's symbol.  If the above returns non-nil, then
comp-el-to-eln-rel-filename will produce the base name of the .eln
file corresponding to a .el file.

The above are the building blocks; what's left is to use them in a
particular case.

> I might want to be sure I've built Emacs with native compilation.

Use native-comp-available-p for this.