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
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel