[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: macOS 64-bit
From: |
Jahrme Risner |
Subject: |
Re: macOS 64-bit |
Date: |
Wed, 16 Oct 2019 20:23:23 +0000 |
On Wed, Oct 16, 2019 at 06:36, Marnen Laibow-Koser <address@hidden> wrote:
> On Tue, Oct 8, 2019 at 2:38 PM Marnen Laibow-Koser <address@hidden>
> wrote:
>
> I’ve been playing around with the MacStadium environment and understanding
> more about the build. Here’s what I think I know so far. Please correct
> me if I’m wrong on any of this.
>
> * A straight compilation, by itself, won’t produce a suitable result. This
> is because LilyPond depends on a bunch of dylibs that have to be installed
> separately. The MacPorts mdmg approach palliates this to some extent, but
> it seems to do so by producing an *installer* which installs the dylibs to
> appropriate places in /opt or elsewhere.
This is largely correct; nit, mpkg builds the installer which on modern macOS
can be distributed as-is while mdmg wraps the installer built by mpkg as a dmg
(disk image) which was necessary for distribution on very old versions of OSX.
> * Better would be a single well-behaved .app bundle, so that no installer
> is necessary. This is how Mac software is typically distributed, and it’s
> how LilyPond has been distributed up to now.
What would the “front-end” be? A .app bundle typically implies some kind of GUI
interface, and my understanding is that the current suggestion is to use
Frescobaldi if one needs an editor and does not already have a preferred text
editor. We might be able to continue to ship the existing editor (if it was
ported to python 3), however macOS is the only distribution handled this way.
Also, I would argue that while .app bundles are *a* norm for distribution,
software of a similar nature to LilyPond, like LaTeX, is typically installed
using either a package manager or an installer (pkg).
> * For that to work, the dylibs need to be moved into the .app bundle.
> There are some tools like dylibbundler that might be able to automate this,
> but the work has already been done in the GUB script that makes the 32-bit
> Mac builds.
Not directly related, but a consideration this comment reminded me of: to make
these dylibs as portable as possible they must be built using as early of an
sdk as possible. While we could choose to simply start supporting 64-bit at
10.15 (Catalina) and instruct users on 10.14 and below to use the x86 build,
this would prevent users of earlier versions from reaping the benefits of the
64-bit build, namely the RAM limits. As such, a better build system might be
OSX 10.8 (Mountain Lion) as this is the first version with a 64-but kernel and
would allow any user who has updated since 2012 to run the application.This may
present issues with MacStadium as I would be surprised if they made it easy to
run arbitrary legacy versions of OSX. I know that MacPorts maintains a set of
build machines running each version of OSX/macOS so whether we end up using
them or not it might be worth reaching out to see what their system for
producing builds is.
> * That being the case, it seems (to my surprise) that the best course of
> action would be to run GUB (with appropriate parameters and an appropriate
> compiler) on Mac OS. Fortunately, this doesn’t look like it will be
> anywhere near as difficult as I’d been led to believe: we’ve got Python and
> a POSIX environment, so it looks like most of it will just work. Figuring
> out the appropriate build options will probably be the biggest challenge.
I admire your optimism! I contributed some work to GUB to get it running on
macOS, though it was having many issues, and the one I was last blocked on,
though I have not looked at for a while, is the inability to compile Perl
through GUB on macOS.
I‘ll try to take another look, though my work has shifted more towards
improving the MacPorts distribution method as I feel that it is a more
sustainable investment.
> A question, BTW: I notice that the file gub/config_cache.py has loads of
> ac_cv_* settings for each build target. I gather that these are Autoconf
> config variables, and that I need to figure out the appropriate settings
> for the 64-bit Mac build. Is there an automated way to do this (say,
> through Autoconf itself), or do I just have to write a C program that calls
> sizeof and so on to find out the values? (Sorry if this is a stupid
> question; I’ve never messed around with Autoconf before.)
I might be mistaken but I believe setting the ac_cv_* variables for
x86_64-darwin might have been part of the changes I submitted, though as I’m
away from my computer atm I cannot check.
I hope I haven’t come across as being pessimistic or discouraging because I
would really love for someone to solve the build/distribute problem. My main
concerns right now are: how can we work to prevent issues like this biting us
again (e.g., if Apple were to move macs off of Intel and onto custom ARM
chips), how can we make the release process as painless as possible, and what
path forward will work for the greatest portion of LilyPond users on macOS? For
me, MacPorts (preferably as a package manager but with the mpkg fallback for
those not wanting to use MacPorts) seems to tick the most boxes out of any of
the suggestion I’ve heard.
Thank you for your work on everything and for exploring MacStadium!
Best,
Jahrme
> Best,
> --
> Marnen Laibow-Koser address@hidden http://www.marnen.org Sent from Gmail
> Mobile
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
- Re: macOS 64-bit, Marnen Laibow-Koser, 2019/10/08
- Re: macOS 64-bit, Marnen Laibow-Koser, 2019/10/16
- Re: macOS 64-bit,
Jahrme Risner <=
- Re: macOS 64-bit, Marnen Laibow-Koser, 2019/10/16
- Re: macOS 64-bit, Werner LEMBERG, 2019/10/17
- Re: macOS 64-bit, Hans Åberg, 2019/10/17
- Re: macOS 64-bit, Marnen Laibow-Koser, 2019/10/17
- Re: macOS 64-bit, Hans Åberg, 2019/10/17
- Re: macOS 64-bit, Marnen Laibow-Koser, 2019/10/17
- Re: macOS 64-bit, Jahrme Risner, 2019/10/19
- Re: macOS 64-bit, Marnen Laibow-Koser, 2019/10/19
- Re: macOS 64-bit, Marnen Laibow-Koser, 2019/10/19
- Re: macOS 64-bit, Marnen Laibow-Koser, 2019/10/20