Re: Linking 64-bit Mac builds from website

[Marnen Laibow-Koser]

On Sun, Mar 8, 2020 at 4:13 PM Jonas Hahnfeld <address@hidden> 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 <address@hidden> 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 <address@hidden>
> 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
address@hidden
http://www.marnen.org