bug#49271: 28.0.50: native-comp: Signing macOS self-contained .app bundle fails due to new *.eln location

[Jim Myhrberg <contact@jimeh.me>]

I've just tried "Contents/lib", and it allowed me to sign and notarize
the .app bundle. And combined with your patch from bug#49270, all
bundled *.eln files are also correctly located and loaded :)

I did a bit of searching myself for alternatives and found
"Contents/PlugIns" as a potentially suitable place, but a quick test
revealed codesign fails the same way with it as it does with
Contents/MacOS.

Personally I think Contents/lib is probably fine, as both codesign and
Apple's notarization process are happy with it. And the notarization
process seems very picky. For example, when *.eln files were in
Resources/native-lisp, my initial notarization attempts failed because
it considered the *.eln files to be binaries, and they had not been
signed by codesign despite the --deep flag being used. Hence I'm
individually signing all the *.eln files before signing the app bundle
itself to get the app through notarization.

Also, I should probably mention that I generally know little about
macOS app development, and have mostly just tested my way forward with
figuring out how to sign and notarize Emacs :)

On Tue, Jun 29, 2021 at 8:19 PM Alan Third <alan@idiocy.org> wrote:
>
> On Tue, Jun 29, 2021 at 12:58:44PM +0100, Jim Myhrberg wrote:
> > Commit 5dd2d50 seems to have moved the native-lisp folder within self-contained
> > Emacs.app bundles:
> >
> > - from: "Contents/Resources/native-lisp"
> > - to:   "Contents/MacOS/lib/emacs/28.0.50/native-lisp"
> >
> > Unfortunately, Apple's codesign utility blows up with an error if there is any
> > folder within "Contents/MacOS" (recursively) which contains two dots within its
> > name. Here is an example of what the error looks like:
> >
> >     /Users/runner/work/emacs-builds/emacs-builds/builds/Emacs.2021-06-26.b8f9e58.master.macOS-10-15.x86_64/Emacs.app:
> > bundle format unrecognized, invalid, or unsuitable
> >     In subcomponent:
> > /Users/runner/work/emacs-builds/emacs-builds/builds/Emacs.2021-06-26.b8f9e58.master.macOS-10-15.x86_64/Emacs.app/Contents/MacOS/lib/emacs/28.0.50
>
> Bummer.
>
> I had three options:
>
>   * Contents/MacOS/lib
>   * Contents/Resources/<something>
>   * Contents/lib
>
> and a close reading of the Apple documentation left me none-the-wiser
> as to which option I should use. Executable binaries go under MacOS,
> but these aren't executables. Framework libraries go somewhere else
> entirely, but these aren't framework libraries. Resources is intended
> for images and things, not libs. Lib is entirely non-standard.
>
> I really don't know where the best place is. I'm still thinking
> Resources is definitely not the right place, but none of the other
> existing places make any sense, so perhaps the non-standard
> /Contents/lib is the best option...
>
> Can you try that? In order to sort it edit configure.ac, search for
> the first occurrence of "ns_applibdir" and change the path.
>
> If that fails then I guess we move them back under Resources. Unless
> you have any better ideas.
> --
> Alan Third