Re: macOS 64-bit

[Jahrme Risner]

Hello Marnen,

Thank you for your input; as one of the people who has been working to get
64-bit Darwin binaries built I can say that more help to get things working
is always a good thing.

I have inserted replies below to some of your comments, though they seem
to have continued growing far past what I was initially intending apologies.

> I hope the post I'm responding to isn't too old to be useful, but:
> -   I'm an active user of Lilypond on Mac OS
> -   I'm concerned about the issues around 64-bit Mac builds
> -   I have some development expertise (though not on Lilypond specifically)
> -   I'm speaking up to make sure that Lilypond continues to be packaged for
>     Mac OS in a way that works well for me
> So if any of that makes my thoughts useful, read on...

Do not let a lack of LilyPond development experience deter you, I have been
working to get to the point of being familiar enough with the source to
contribute to LilyPond itself, but generally that specific knowledge is not
necessary to contribute to packaging unless a bug presents itself only when
performing the current packaging.

> I think this is poor advice. IMHO MacPorts is very hard to work with (as an
> end user) compared to Homebrew, and I haven't seen anyone using MacPorts on
> their Mac in well over a decade. It seems to pop up mostly in developer
> communities like this one (and that of Inkscape), but it's not popular in
> the wider Mac community.

I would be interested to hear (specifically) what about MacPorts makes it
hard to work with compared to Homebrew. Having used Homebrew for several years
but recently working with MacPorts (in part because of LilyPond) I have not
found MacPorts to be "more difficult" than Homebrew other than perhaps the
installation. This is not to be dismissive of any difficulties you have
encountered, I simply want to understand better.

> For myself, I hate MacPorts so much that if LilyPond came to require
> MacPorts, I'd seriously consider switching to MuseScore despite the
> somewhat lower engraving quality. I just don't want MacPorts anywhere near
> my computer, and I hope I will not be forced to use it in order to continue
> to use LilyPond on my Mac.

In my understanding it will never be *necessary* to run MacPorts (there will
always be the option to compile it yourself), but it could become the/one of
the recommended ways to install LilyPond on macOS. Further, MacPorts has the
ability to create "bundles" that can be installed via dmg, pkg, or tar archive
without MacPorts. The current issue with this method of packaging is that the
MacPorts bundling includes *all* dependencies (including build-time
dependencies) which causes the package to be much too large for reasonable
distribution. If the size of the package can be reduced (one avenue that I
have been exploring), it may be that macOS is handled much the same as it is
currently, but with the package generated by MacPorts instead of GUB.

> My understanding from other posts here (correct me if I'm wrong) is that a
> major (legal, not technical) roadblock for doing this with GUB is the
> licensing requirement that seems to require that Xcode be run on Apple
> hardware, and the lack of consistent availability of Apple hardware for
> builds.

In my opinion, the largest issue here is that any *developers* working to
fix/improve/modify LilyPond who do not *personally* have access to Apple
hardware cannot test how their change will affect Darwin. With every other
system a developer could create a VM to test build results (even Windows,
though a license would be required) but not so with Darwin.

> If that's so, then I have a suggestion that doesn't seem to have been made
> at least on this list so far. Travis CI provides a cloud-based Mac build
> environment (see https://docs.travis-ci.com/user/reference/osx/ for
> specifics), and like all of Travis's services, this is available free of
> charge to open-source projects. If we can get GUB or something else suitable
> to run on Travis's Mac build environment (which seems likely), then our Mac
> build issue should be solved, right?

There are several considerations here.

First, GUB cannot currently build for 64-bit Darwin even on macOS. Thus, in
order for Travis CI (or some alternative) to even be relevant we must first be
able to determine a/the way to build LilyPond on macOS.

Second, one of the consistent issues which Travis CI would not be able to
solve is the dependence on LaTeX (texlive). There is not, AFAIK, *any* elegant
solution to the usage of texlive on macOS. Homebrew, which is the package
manager used for macOS builds on Travis CI, has chosen to completely remove
texlive and all[*] related packages.
        * There may be a few packages that have found workarounds,
          but if so they are few and far-between.
As such, from my reading, the most common workaround to build and use Docker
images inside of Travis CI to run texlive related programs which would add an
extra level of complexity.

Third, assuming Travis CI *could* build LilyPond successfully and was the
recommended way to build for macOS, I believe there should be some way for
developers to request builds when testing patches/changes to ensure that
changes are not breaking macOS builds. The most common way to request Travis
CI builds (in my understanding) is through Pull Requests which trigger
automatic builds. This would then likely require someone to maintain a GitHub
mirror of the LilyPond source from which developers could request builds. This
itself presents issues with either requiring developers to create GitHub
accounts or for someone else to submit changes for testing on their behalf.

A better alternative (in my opinion) would be to set up some form of
continuous integration for LilyPond in general that could automate this
testing for all proposed patches. While slightly off-topic, I know that it has
previously been proposed to consider using GitLab. My understanding is that
GitLab's CI feature is considered to be one of the best free CI services
available. The main drawback to GitLab's CI is that the "runners" must be
provided by the organization, so this would necessitate either a physical or
virtual mac; though MacStadium does offer free hosting for open source usage.

A couple of links for the curious:
- GitLab's announcement of free "premium" accounts for open source.
https://about.gitlab.com/2018/06/05/gitlab-ultimate-and-gold-free-for-education-and-open-source/
- GitLab's general page on CI.
https://about.gitlab.com/product/continuous-integration/
- MacStadium's page on free hosting for open source.
https://www.macstadium.com/opensource

> If that's so and it seems interesting, I could probably put some effort into
> getting a Travis Mac build environment set up (though I don't expect to have
> much free time before July). I've used Travis on many projects in the past
> and I'm reasonably familiar with it.

While I would never presume to say "no" to a project someone is interested in,
I would recommend holding off on investing any serous amount of time in
Travis builds until macOS build are working on macOS and there has been some
more discussion on the preferred build/distribution work-flow going forward.

Best wishes,
Jahrme

publickey - lilypond@jahrme.com - 0x307E3DA6.asc
Description: application/pgp-keys