Re: Finalizing 'inhibit-automatic-native-compilation'

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org,  akrl@sdf.org,  larsi@gnus.org,  rlb@defaultvalue.org
> Date: Sun, 29 Jan 2023 21:30:41 -0500
> 
> >> > IMO, the "no writable eln-cache" scenario should be solved by tweaking
> >> > native-comp-eln-load-path to include a writable directory.  That
> >> > writable directory could be temporary-file-directory, or it could be
> >> > anything else, but it should be specified by the caller/user, not
> >> > pulled out of our hat behind the scenes.
> >> 
> >> That's where I disagree: when it comes to trampolines I think users
> >> would be better served if we silently used an eln-cache in
> >> `temporary-file-directory` rather than ignoring the subr's redefinition
> >> (usually due to an advice).
> >
> > Why? in the Debian use case all they care about is that the file is
> > not written to HOME, and my proposal doesn't break that.
> 
> AFAIK your proposal breaks some uses of advice.

Are you alluding to some uses we've heard about, or is this just a
theoretical possibility?  AFAIU, for this to be a real issue, we'd
need a use where the user (a) disables native-compilation for some
reason, but (b) still wants advices of natively-compiled code to
work.  Why would someone do something like that?

> > The trampoline isn't needed in their scenario, so there's no reason to
> > generate it.
> 
> I don't know if they need trampolines, but I wouldn't be surprised if
> they do on occasion.

We'd need them to answer that and explain.