Re: macOS 64-bit

[Jahrme Risner]

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