Re: macOS 64-bit

[Marnen Laibow-Koser]

On Wed, Oct 16, 2019 at 4:23 PM Jahrme Risner <address@hidden> wrote:

>
>
> 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:
>
> [...]

>
> * 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.
>

I think I was aware of that.  :) Thanks for the clarification.


> * 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?


Lilypad has been adequate for this up to now.

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.


And that would be my suggestion too.


We might be able to continue to ship the existing editor (if it was ported
> to python 3),


What does Python 3 have to do with it?  (I haven’t looked at the Lilypad
code yet.)

however macOS is the only distribution handled this way.


Understood.  I think that this approach still makes sense.


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).
>

LaTeX is mostly used by technical people.  I’d venture to guess that most
of LilyPond’s target users on Mac OS have never even *heard* of a package
manager.  Besides, LilyPond has a lot of runtime dependencies, and an .app
bundle corrals them all nicely.

Also, the closest alternatives to LilyPond are MuseScore, Finale, Sibelius,
and so on.  None requires a package manager to install on Mac OS.  Neither
does Frescobaldi, for that matter.  Neither should LilyPond, if we want
nontechnical folks to use it.

In a perfect world, the app bundle would contain a *decent* editor. :)
Maybe Frescobaldi.  But that’s beyond the scope of this particular
project.  I just want to get *something* working.

[...]

> 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.


Prepare to be surprised, then! :) The MacStadium box is running Yosemite
(10.10), which was the oldest version I could easily get, for precisely
this reason.  But it’s also no big deal: older versions of Mac OS can still
use the 32-bit builds from the Linux GUB instance, right?


>
> * 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’m currently working on that, building on your existing work.  It looks
like some of GUB’s build flags for Perl are just plain *st00pid* on Mac OS,
and so I plan to modify or disable them for a Darwin build environment.

This process has far too much yak shaving.  The fact that GUB is necessary
suggests that LilyPond’s build process is more complex than it needs to
be...



> 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.
>

As long as it doesn’t force the end user into installing MacPorts itself.


> 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.
>

Yeah, I found your pull request and I’m currently using that as part of my
branch.  Thanks!


>
>
> 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.
>

I think I’m fairly close.  We’ll see if I’m right. :)

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),
>

By building on the target platform like nearly everyone else does. :)  A
system like GUB should IMHO be a supplement to native builds, not a
replacement for them.

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.
>

I’m mystified by the love for MacPorts that I’ve heard from you and others
in this group.  It’s got some advantages on a build box, but I don’t know
*anyone* these days, outside of this group, who uses it on an end-user
machine.  In the communities I’m familiar with, everyone uses Homebrew if
they use a package manager at all, and it’s been this way for years.

Maybe *you* find MacPorts preferable, but that view doesn’t reflect that of
the majority of the end users I’ve run into.

Anyway, glad to hear that you’ll be thinking of the mpkg approach.  I
suspect if the project goes that route, the majority of users would take
that option.  I know I would.


> Thank you for your work on everything and for exploring MacStadium!
>

And thanks for your contributions!


> Best,
> Jahrme
>

Best,

> --
Marnen Laibow-Koser address@hidden http://www.marnen.org Sent from Gmail
Mobile