On Sun, Mar 8, 2020 at 4:13 PM Jonas Hahnfeld <[email protected]> wrote:
> Am Sonntag, den 08.03.2020, 16:04 -0400 schrieb Marnen Laibow-Koser: > > On Sun, Mar 8, 2020 at 3:43 PM Jonas Hahnfeld <[email protected]> wrote: > > > Am Sonntag, den 08.03.2020, 15:23 -0400 schrieb Marnen Laibow-Koser: > > > > > > > > > > > > On Sun, Mar 8, 2020 at 2:38 PM Jonas Hahnfeld <[email protected]> > wrote: > > > > > Am Sonntag, den 08.03.2020, 14:23 -0400 schrieb Marnen > Laibow-Koser: > > > > [...] > > > > > It might be worth holding off this level of automation for a bit. > > > > > > > > Why? It’s common and (in the general case) easy to do with modern > CI/CD infrastructure. Besides, if we don’t do it, then the 64-bit Mac > builds will be less generally available, and that will negate the point of > all my work on them. > > > > > > I'm not saying that you shouldn't upload it (even though it kind of > > > feels like a third party package right now). > > > > How does it feel like a third-party package? I'm basically duplicating > the structure of the official 32-bit Mac builds, except that I'm not using > GUB. > > Exactly, precisely what I said. > That does not clarify what you meant. I still do not understand. > > > > > > Besides how often do you > > > expect rebuilds for each release? That's hopefully one binary package > > > per LilyPond release, right? > > > > At least. Ideally I'd like to also make available a "bleeding-edge" > .app build, either nightly or for each commit accepted into master. But > that's less important than making builds available for each release, of > course. > > > > > > > > > > Or are you suggesting another way to make the builds generally > available? If so, what? Right now I’m manually uploading them to Bintray, > which isn’t sustainable (although I *could* automate that through their > API). > > > > > > > > > > > > > I > > > > > hope we can switch all platforms away from GUB, > > > > > > > > I do too. It’s a good idea in theory, but *way* too complicated. > > > > Clarification: I meant that *GUB* is way too complicated. I would like > to switch to a simpler build method. > > > No, it works: https://github.com/hahnjo/lilypond-binaries/ > > > > What is that? It has no description or README, and I cannot easily tell > what it is meant to do. > > "There hasn't been a thread on lilypond-devel about this yet because > I'm waiting for 2.21.0 which we'll do with GUB." > ...which will not produce a 64-bit Mac build, so we're in the same position we were in with 2.19 and 2.20. > > > > > > And unless proven wrong, I think this will also work for macOS (given a > > > few tweaks). > > > > We *already* have something working for macOS, as I've made clear on > this list. See https://bintray.com/marnen/lilypond-darwin-64 and > http://gitlab.com/marnen/lilypond-mac-builder ;. If you think my work > can be improved by yours, or vice versa, pull requests are welcome! > > Yes, I think it can be improved: There should not be separate ways to > build release binaries for each platform. I think I agree with you, and *in theory* I believe the Mac Makefile I wrote could be made platform-independent. However, *in practice*, the way native dependencies—and packaging—is managed on each platform is quite different (Mac OS works best with .app bundles, other *nix wants naked executables installed through a package manager, I have no idea how things work on Windows), so how do we *get* to this point without just reimplementing GUB, unless we somehow make the LilyPond codebase itself less dependent on external binaries? > I suggested that we > collaborate back in January. > At the time, you didn't seem to provide anything useful to work with. I wasn't even aware of the lilypond-binaries repo till just now; as you said, you never mentioned it on the list, and I don't think you ever told me about it directly either, which means that I didn't know that there was anything to collaborate *with* beyond some early sketches. :) Anyway, I'd be happy to collaborate, but my proximate concern is ensuring the continued availability of 64-bit Mac .app bundles. As long as we can keep doing that, I would *love* to improve the process for it. In other words: this is kind of all bikeshedding right now. I have something usable today, and while we absolutely should improve the process going forward, we shouldn't do that at the expense of the currently usable thing today. > Jonas > Best, -- Marnen Laibow-Koser [email protected] http://www.marnen.org
