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

[Eli Zaretskii]

> From: Aymeric Agon-Rambosson <aymeric.agon@yandex.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org, akrl@sdf.org, larsi@gnus.org, rlb@defaultvalue.org
> Date: Mon, 06 Feb 2023 11:57:41 +0100
> 
> Hello everyone, and sorry for my being late.

Thanks for chiming in.

> >>   . where and under what circumstances will those advised 
> >>   functions be
> >>     called, as part of your preparation of the packages?  (if 
> >>     the
> >>     advised functions are only called when the end-user uses 
> >>     the
> >>     package, that is not relevant to the present discussion)
> 
> As far as we can tell, this advising of primitives happens mostly 
> in tests, that is in our build environment on our build machines.

Test harnesses frequently need to jump through various hoops,
certainly so when they need to mock-out some APIs to do their job.

> >>   . if we provide a way to specify, via 
> >>   comp-enable-subr-trampolines,
> >>     the directory to which the trampolines will be written, 
> >>     will that
> >>     satisfy your uses? if not, why not (details, please)?
> >>   . why cannot you use native-comp-eln-load-path to force the
> >>     trampolines go to a directory of your choice?
> 
> In this case, this is not pertinent. We need to :
> - either not to have to install a trampoline
> - or, if we have to, be certain to find it in the *first* 
>   directory returned by `comp-eln-load-path-eff'.

I don't think I understand: the output of that function depends on
native-comp-eln-load-path, so why tweaking that is not enough?

> If neither condition are met, we reach the error. The only 
> variables that are of help here are 
> `native-comp-never-optimize-functions' or 
> `comp-enable-subr-trampolines'.

If those can help you solve your problem, I think that's "good enough"
for something that needs to be done in a test suite.  My primary
target audience, in contrast, is Emacs users.

> Since EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION acts on neither 
> of these, we have to manually add
> 
> (with-eval-after-load 'comp (push 'insert-file-contents 
> native-comp-never-optimize-functions))
> 
> At the beginning of the test file.

A similar solution could have solved your problem even if
inhibit-automatic-native-compilation didn't exist at all,and we only
had comp-enable-subr-trampolines and native-comp-deferred-compilation,
right?

> For this reason, it would be nice, if possible, that 
> EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION also disables 
> trampoline compilation, for instance by setting 
> `comp-enable-subr-trampolines'. The name of the environment 
> variable would be changed accordingly, of course.

Why do you need this to be done together with disabling native
compilation? why not do it with two separate settings?

> >> I dislike having environment variables that alter Emacs 
> >> behavior,
> >> because environment variables are inherited by sub-processes.
> 
> This is precisely why I like it. Our build mechanism can have 
> emacs instances nested deep in layers of wrapper scripts. Because 
> of this, we can simply export the variable in the environment of 
> the ancestor process, and not worry about adding --eval arguments 
> in various places in the middle of our scripts. But only the 
> descendants of this ancestor process are concerned by this 
> environment variable, and they live only as long as the building 
> mechanism runs, so I don't see the reason for worry. Then, if 
> users want to use this variable in normal use, and they decide on 
> top of that to have multiple nested emacsen, then I agree that 
> they have to be careful, but that situation seems a bit 
> far-fetched.

I understand the convenience, but once again, my primary audience is
the Emacs users, and they rarely need to handle such convoluted
situations.  Some relative inconvenience aside, I see no reason why
you couldn't make do without the environment variable, but via some
automatically-loaded init files or somesuch.

Thanks.