bug#27810: NS runtime feature detection

[David Caldwell <david@porkrind.org>]

[-- Attachment #1.1: Type: text/plain, Size: 4468 bytes --]

On 8/12/17 8:51 AM, Alan Third wrote:
> On Sat, Aug 12, 2017 at 01:13:56PM +0200, Charles A. Roelli wrote:
>> Hm, on second thoughts, it seems a bit overwrought to try doing this
>> weak linking only for the sake of forward-compatible builds.  It
>> should be enough to support only backward-compatible builds, so that
>> we might one day distribute Emacs as a .dmg (built on the latest macOS
>> and backwards-compatible with the oldest version of macOS that we
>> support).
> 
> I think this makes sense. Especially given we’re not able to actually
> create a stand‐alone .app without implementing something like...
> 
>> I also looked at the emacsformacosx.com build scripts, and it seems
>> like they're making copies of Emacs' dependent dynamic libraries,
>> including them in the application bundle, then using
>> install_name_tool(1) to patch the Emacs binary to depend on them (I
>> don't understand, though, how those scripts resolve dependencies
>> between the dynamic libraries themselves).

The install_name_tool stuff is to change the absolute paths in the
dynamic library load paths to application relative paths. And only for
extra dependency stuff that gets installed like gnutls (and eventually
more—I'd like ImageMagick, but I haven't been able to get relative paths
working with its plugin-architecture).

The relative paths still include the OS that they were compiled on so
the dylibs can find each other but not conflict with the other OS dylibs.

For instance, Emacs-Emacs.app/Contents/MacOS/Emacs-x86_64-10_9 has this
as one of it's load paths:

  @executable_path/lib-x86_64-10_9/libgnutls.30.dylib

and Emacs.app/Contents/MacOS/lib-x86_64-10_9/libgnutls.30.dylib has
stuff like:

  @executable_path/lib-x86_64-10_9/libp11-kit.0.dylib

It's pretty straightforward in the end, but it's not documented super
well, and it's sort of tricky that you have to manipulate all these
things manually.

> I wouldn’t have a problem with putting this capability in, but I don’t
> have the knowledge nor the inclination to do it myself.
> 
> I was going to write something up in INSTALL about building with
> feature detection, but I really don’t know how to put it. I don’t want
> to give the impression that if you use
> -DMAC_OS_X_VERSION_MIN_ALLOWED=1060 that it will magically build a
> portable .app. I began to wonder if it’s worth mentioning at all since
> I doubt any more than a handful of people will be interested in
> building with this option.
> 
> David and David, I hope it’s OK to include you in this. I thought you
> might be interested and perhaps have some thoughts on what we’re
> doing.
> 
> Basically, instead of detecting all macOS features at compile‐time,
> we’ve stuck in some code to detect them at run‐time. It causes
> compiler warnings, so by default it still limits features to those
> available at build‐time, but if you do something like:
> 
>     ./configure --with-ns CFLAGS="-DMAC_OS_X_VERSION_MIN_REQUIRED=1060 -O3 -g"
> 
> when building on macOS Sierra, you should, in theory, end up with an
> executable that will work correctly on every version of macOS back to
> 10.6, inclusive. We haven’t been able to properly test portability yet
> as it requires including dynamic libraries.

I would love that. As far as I know, that's the way Apple recommends
doing feature detection. Many of the complexities of the
EmacsForMacOS.com builds (like all the individual OS compiled versions)
are because Emacs does compile-time feature detection instead of
run-time. Compiling on old systems means having to jump through hoops
sometimes as different software stops being supported on them. I have to
download a "portable ruby" binary that homebrew made so that I can run
something newer than 1.8 on old OSes. For master branch builds I have to
run the autoconf stuff on an up-to-date Debian machine before handing it
off to the Mac build machines because it's really hard to automate
installing the latest autoconf in a way that supports stuff back to 10.6
(Homebrew is not available on 10.6, for instance).

So having a single backwards compatible version of Emacs would be very
very nice. The build-system is rickety and this would make it more
streamlined. And much easier for a random person to build a universal
app (btw I'd be happy to help produce official Mac builds if that is
ever wanted).

-David


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]