unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#48108: Fwd: Wishlist: Command to remove redundant eln cache directories [native-comp]
       [not found] <CAAeL0SRmG9KtR7PLcmYrS2DUsiuWz72stWz=ir5F02rZnLfJ3A@mail.gmail.com>
@ 2022-11-28  8:59 ` Juanma Barranquero
  2022-11-28 12:44 ` bug#48108: " Eli Zaretskii
  1 sibling, 0 replies; 12+ messages in thread
From: Juanma Barranquero @ 2022-11-28  8:59 UTC (permalink / raw)
  To: 48108

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

`native-compile-prune-cache' does not remove the preloaded/ subdir (or its
contents) of the native-lisp/ directories, and consequently does not remove
the directories themselves.

For example, after running it I still have *.eln files in the following
directories (comp-native-version-dir = "29.0.50-c0f9fe8e"):

~/.emacs.d/.eln-cache/29.0.50-c0f9fe8e
D:\Devel\emacs\repo\trunk\native-lisp\29.0.50-57ea32b2\preloaded
D:\Devel\emacs\repo\trunk\native-lisp\29.0.50-7c1dd663\preloaded
D:\Devel\emacs\repo\trunk\native-lisp\29.0.50-a22e1c10\preloaded
D:\Devel\emacs\repo\trunk\native-lisp\29.0.50-c0f9fe8e\preloaded

which means the command deleted the stale cache in ~/.emacs.d/, but not the
ones in the source tree.

Is that intended?

[-- Attachment #2: Type: text/html, Size: 1071 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48108: Wishlist: Command to remove redundant eln cache directories [native-comp]
       [not found] <CAAeL0SRmG9KtR7PLcmYrS2DUsiuWz72stWz=ir5F02rZnLfJ3A@mail.gmail.com>
  2022-11-28  8:59 ` bug#48108: Fwd: Wishlist: Command to remove redundant eln cache directories [native-comp] Juanma Barranquero
@ 2022-11-28 12:44 ` Eli Zaretskii
  2022-11-28 13:09   ` Juanma Barranquero
  1 sibling, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2022-11-28 12:44 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: larsi, 48108, stefankangas

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 28 Nov 2022 09:39:14 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Kangas <stefankangas@gmail.com>, 
> 	Lars Ingebrigtsen <larsi@gnus.org>
> 
> `native-compile-prune-cache' does not remove the preloaded/ subdir (or its contents) of the native-lisp/
> directories, and consequently does not remove the directories themselves.
> 
> For example, after running it I still have *.eln files in the following directories (comp-native-version-dir =
> "29.0.50-c0f9fe8e"):
> 
> ~/.emacs.d/.eln-cache/29.0.50-c0f9fe8e
> D:\Devel\emacs\repo\trunk\native-lisp\29.0.50-57ea32b2\preloaded
> D:\Devel\emacs\repo\trunk\native-lisp\29.0.50-7c1dd663\preloaded
> D:\Devel\emacs\repo\trunk\native-lisp\29.0.50-a22e1c10\preloaded
> D:\Devel\emacs\repo\trunk\native-lisp\29.0.50-c0f9fe8e\preloaded
> 
> which means the command deleted the stale cache in ~/.emacs.d/, but not the ones in the source tree.
> 
> Is that intended?

AFAIR, yes.  The command is intended to help users to clean up the eln-cache
of files _they_ compile, but it isn't supposed to touch *.eln files
installed as part of Emacs.  That's for sysadmins.  And besides, on many
systems the preloaded *.eln files are not writable by "normal" users.

See bug#48108, where this was discussed.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48108: Wishlist: Command to remove redundant eln cache directories [native-comp]
  2022-11-28 12:44 ` bug#48108: " Eli Zaretskii
@ 2022-11-28 13:09   ` Juanma Barranquero
  2022-11-28 13:22     ` Juanma Barranquero
  2022-11-28 13:38     ` Eli Zaretskii
  0 siblings, 2 replies; 12+ messages in thread
From: Juanma Barranquero @ 2022-11-28 13:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 48108, stefankangas

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

Some of the weird things I see are perhaps the consequence of running Emacs
in place from the build tree.

It is assumed that normal users have write access to
native-lisp/VERSION-xxxxxxxx/, but not to
native-lisp/VERSION-xxxxxxx/preloaded?

The function already deletes any *.eln file in a stale native
VERSION-xxxxxxx directory, just not the ones in preload/

[-- Attachment #2: Type: text/html, Size: 543 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48108: Wishlist: Command to remove redundant eln cache directories [native-comp]
  2022-11-28 13:09   ` Juanma Barranquero
@ 2022-11-28 13:22     ` Juanma Barranquero
  2022-11-28 13:43       ` Eli Zaretskii
  2022-11-28 13:38     ` Eli Zaretskii
  1 sibling, 1 reply; 12+ messages in thread
From: Juanma Barranquero @ 2022-11-28 13:22 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 48108, stefankangas

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

Also, if you set a relative path in native-comp-eln-load-path (directly,
not via `startup-redirect-eln-cache'), it defaults to
`invocation-directory', which is (in an in-place run) the src/ subdir.

Which is weird:

(push "./test-native" native-comp-eln-load-path)

and then the test-native/ subdir is created both under
`user-emacs-directory' and `invocation-directory' (the .eln files go to the
second one).

[-- Attachment #2: Type: text/html, Size: 561 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48108: Wishlist: Command to remove redundant eln cache directories [native-comp]
  2022-11-28 13:09   ` Juanma Barranquero
  2022-11-28 13:22     ` Juanma Barranquero
@ 2022-11-28 13:38     ` Eli Zaretskii
  2022-11-28 13:48       ` Juanma Barranquero
  1 sibling, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2022-11-28 13:38 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: larsi, 48108, stefankangas

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 28 Nov 2022 14:09:42 +0100
> Cc: larsi@gnus.org, 48108@debbugs.gnu.org, stefankangas@gmail.com
> 
> Some of the weird things I see are perhaps the consequence of running Emacs in place from the build tree.
> 
> It is assumed that normal users have write access to native-lisp/VERSION-xxxxxxxx/, but not to
> native-lisp/VERSION-xxxxxxx/preloaded?

No, to both.

> The function already deletes any *.eln file in a stale native VERSION-xxxxxxx directory, just not the ones in
> preload/

That's a bug, IMO.  The last directory in native-comp-eln-load-path should
not be emptied.  On a multi-user system, some other user could run an Emacs
that uses the files in the native-lisp/VERSION-xxxxxxx/ directory.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48108: Wishlist: Command to remove redundant eln cache directories [native-comp]
  2022-11-28 13:22     ` Juanma Barranquero
@ 2022-11-28 13:43       ` Eli Zaretskii
  2022-11-28 13:54         ` Juanma Barranquero
  0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2022-11-28 13:43 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: larsi, 48108, stefankangas

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 28 Nov 2022 14:22:05 +0100
> Cc: larsi@gnus.org, 48108@debbugs.gnu.org, stefankangas@gmail.com
> 
> Also, if you set a relative path in native-comp-eln-load-path (directly, not via `startup-redirect-eln-cache'), it
> defaults to `invocation-directory', which is (in an in-place run) the src/ subdir. 
> 
> Which is weird:
> 
> (push "./test-native" native-comp-eln-load-path)
> 
> and then the test-native/ subdir is created both under `user-emacs-directory' and `invocation-directory' (the
> .eln files go to the second one).

Why is this weird?  These files are needed early at startup, when Emacs is
still unable to do anything fancy, so how is it "weird" that relative file
names are interpreted as relative to where Emacs runs?  Are you aware of any
other programs that interpret relative file names differently?

If the effect surprises you, don't add relative file names to the variable.
You aren't supposed to anyway; AFAIR this option is only used during the
build, if at all.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48108: Wishlist: Command to remove redundant eln cache directories [native-comp]
  2022-11-28 13:38     ` Eli Zaretskii
@ 2022-11-28 13:48       ` Juanma Barranquero
  0 siblings, 0 replies; 12+ messages in thread
From: Juanma Barranquero @ 2022-11-28 13:48 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 48108, stefankangas

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

On Mon, Nov 28, 2022 at 2:38 PM Eli Zaretskii <eliz@gnu.org> wrote:

That's a bug, IMO.  The last directory in native-comp-eln-load-path should
> not be emptied.  On a multi-user system, some other user could run an Emacs
> that uses the files in the native-lisp/VERSION-xxxxxxx/ directory.
>

I'll create a bug report for that, then.

[-- Attachment #2: Type: text/html, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48108: Wishlist: Command to remove redundant eln cache directories [native-comp]
  2022-11-28 13:43       ` Eli Zaretskii
@ 2022-11-28 13:54         ` Juanma Barranquero
  2022-11-28 14:44           ` Eli Zaretskii
  0 siblings, 1 reply; 12+ messages in thread
From: Juanma Barranquero @ 2022-11-28 13:54 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 48108, stefankangas

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

On Mon, Nov 28, 2022 at 2:42 PM Eli Zaretskii <eliz@gnu.org> wrote:

Why is this weird?  These files are needed early at startup, when Emacs is
> still unable to do anything fancy, so how is it "weird" that relative file
> names are interpreted as relative to where Emacs runs?  Are you aware of
> any
> other programs that interpret relative file names differently?
>

It is used also for files that are not required early at startup (unless
you consider "early at startup" native-compiling the .el/.elc files
required or loaded in init.el).

If the effect surprises you, don't add relative file names to the variable.
>

For sure.


> You aren't supposed to anyway; AFAIR this option is only used during the
> build, if at all.
>

 I don't disagree, but that's not evident reading
native-comp-eln-load-path's docstring.

Anyway, the fact that if you set a relative dir ./test-compile in that
variable both ~/.emacs.d/test-compile and src/test-compile directories are
created is also a bug.

[-- Attachment #2: Type: text/html, Size: 1988 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48108: Wishlist: Command to remove redundant eln cache directories [native-comp]
  2022-11-28 13:54         ` Juanma Barranquero
@ 2022-11-28 14:44           ` Eli Zaretskii
  2022-11-28 15:14             ` Juanma Barranquero
  0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2022-11-28 14:44 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: larsi, 48108, stefankangas

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 28 Nov 2022 14:54:32 +0100
> Cc: larsi@gnus.org, 48108@debbugs.gnu.org, stefankangas@gmail.com
> 
> On Mon, Nov 28, 2022 at 2:42 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
>  Why is this weird?  These files are needed early at startup, when Emacs is
>  still unable to do anything fancy, so how is it "weird" that relative file
>  names are interpreted as relative to where Emacs runs?  Are you aware of any
>  other programs that interpret relative file names differently?
> 
> It is used also for files that are not required early at startup (unless you consider "early at startup"
> native-compiling the .el/.elc files required or loaded in init.el).

I do.

>  You aren't supposed to anyway; AFAIR this option is only used during the
>  build, if at all.
> 
>  I don't disagree, but that's not evident reading native-comp-eln-load-path's docstring.

This is Emacs: you get enough rope to hang yourself.  We trust you that you
either know what you are doing, or won't do it.

> Anyway, the fact that if you set a relative dir ./test-compile in that variable both ~/.emacs.d/test-compile and
> src/test-compile directories are created is also a bug.

Why do you think it's a bug?





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48108: Wishlist: Command to remove redundant eln cache directories [native-comp]
  2022-11-28 14:44           ` Eli Zaretskii
@ 2022-11-28 15:14             ` Juanma Barranquero
  2022-11-28 16:48               ` Eli Zaretskii
  0 siblings, 1 reply; 12+ messages in thread
From: Juanma Barranquero @ 2022-11-28 15:14 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Lars Magne Ingebrigtsen, 48108, stefankangas

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

On Mon, Nov 28, 2022, 15:43 Eli Zaretskii <eliz@gnu.org> wrote:

>
> This is Emacs: you get enough rope to hang yourself.  We trust you that you
> either know what you are doing, or won't do it.
>

Still, a brief reminder/warning in the docstring would be nice. We warn,
occasionally.

>
> Why do you think it's a bug?
>

Because the ~/. emacs.d/ one is created but left empty.

>

[-- Attachment #2: Type: text/html, Size: 1098 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48108: Wishlist: Command to remove redundant eln cache directories [native-comp]
  2022-11-28 15:14             ` Juanma Barranquero
@ 2022-11-28 16:48               ` Eli Zaretskii
  2022-11-28 16:53                 ` Juanma Barranquero
  0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2022-11-28 16:48 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: larsi, 48108, stefankangas

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 28 Nov 2022 16:14:27 +0100
> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>, 48108@debbugs.gnu.org, stefankangas@gmail.com
> 
> On Mon, Nov 28, 2022, 15:43 Eli Zaretskii <eliz@gnu.org> wrote:
> 
>  This is Emacs: you get enough rope to hang yourself.  We trust you that you
>  either know what you are doing, or won't do it.
> 
> Still, a brief reminder/warning in the docstring would be nice. We warn, occasionally. 
> 
>  Why do you think it's a bug?
> 
> Because the ~/. emacs.d/ one is created but left empty. 

I still don't understand why would that constitute a bug.  It is created so
that future compilation wouldn't have to worry about its existence if and
when they need to deposit *.eln files there.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48108: Wishlist: Command to remove redundant eln cache directories [native-comp]
  2022-11-28 16:48               ` Eli Zaretskii
@ 2022-11-28 16:53                 ` Juanma Barranquero
  0 siblings, 0 replies; 12+ messages in thread
From: Juanma Barranquero @ 2022-11-28 16:53 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 48108, stefankangas

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

On Mon, Nov 28, 2022 at 5:48 PM Eli Zaretskii <eliz@gnu.org> wrote:

I still don't understand why would that constitute a bug.  It is created so
> that future compilation wouldn't have to worry about its existence if and
> when they need to deposit *.eln files there.
>

Because preventively creating subdirs that will, or will not, ever be used
is untidy.

Also, because if someone has taken the effort of setting the variable, it's
quite possible they don't want .eln files in ~/.emacs.d/

Yes, they should use an absolute path, and/or `startup-redirect-eln-cache'
(preferably).

[-- Attachment #2: Type: text/html, Size: 1204 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2022-11-28 16:53 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAAeL0SRmG9KtR7PLcmYrS2DUsiuWz72stWz=ir5F02rZnLfJ3A@mail.gmail.com>
2022-11-28  8:59 ` bug#48108: Fwd: Wishlist: Command to remove redundant eln cache directories [native-comp] Juanma Barranquero
2022-11-28 12:44 ` bug#48108: " Eli Zaretskii
2022-11-28 13:09   ` Juanma Barranquero
2022-11-28 13:22     ` Juanma Barranquero
2022-11-28 13:43       ` Eli Zaretskii
2022-11-28 13:54         ` Juanma Barranquero
2022-11-28 14:44           ` Eli Zaretskii
2022-11-28 15:14             ` Juanma Barranquero
2022-11-28 16:48               ` Eli Zaretskii
2022-11-28 16:53                 ` Juanma Barranquero
2022-11-28 13:38     ` Eli Zaretskii
2022-11-28 13:48       ` Juanma Barranquero

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).