Re: Deferring native compilation finalization until idle

On Sat, Jul 25, 2026 at 1:38 PM Lynn Winebarger <[email protected]> wrote:

> On Sat, Jul 25, 2026, 12:23 PM Aaron Jensen <[email protected]> wrote:
>
>>
>> No, this is not what the problem is. That's the thing that I'm saying has
>> been pretty well established in this thread, though it seems not well
>> enough.
>>
>> The problem is that macOS, upon first *loading* the bundle in the main
>> Emacs process will undergo a security check (the one disabled by the
>> entitlements call you posted). This is a synchronous, blocking operation.
>> MacOS does not allow the process to load the bundle until it has verified
>> it, so the load is blocking.
>>
>
> Just out of curiosity, could this be approached by treating the
> verification step as part of the compilation?  Could the library be
> verified while loaded from some non-standard location (in an asynchronous
> instance of Emacs) then moved to the ordinary eln cache directory?  Or, if
> it must be verified in place, only load verified libraries implicitly
> (launching asynchronous instances to do the verification load as necessary)?
>

I dunno about that but it may be the case that if one has runtime
permissions to create files under their Emacs.app bundle directory, and if
those files are excluded from validation by definition, that their eln
cache could point there.  In the jimeh build case it could point
into Emacs.app/Contents/Frameworks/native-lisp/32_0_50-9f204206 where
Emacs.app lives in /Applications or ~/Applications.  For the case of
running from the source tree, it would have to be installed into the source
tree in an extra step.

>