bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27810: NS runtime feature detection


From: David Reitter
Subject: bug#27810: NS runtime feature detection
Date: Tue, 12 Sep 2017 16:06:20 -0400

All,
If I haven’t replied to this earlier (sorry), I second David’s comments.  
The distributed binary version of Aquamacs is built with an environment that 
hides installed libraries as far as possible, and with patches that add runtime 
checks for the availability of APIs.

I never understood why the Emacs build on Macs does so much compile-time 
checking, and I can only suspect that there are historical reasons from 
GNU/Linux systems where you have source distributions, build locally, using 
package managers to take care of dependencies.

- David


> On Sep 12, 2017, at 4:01 PM, David Caldwell <address@hidden> wrote:
> 
> 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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]