Re: macOS 64-bit

[Marnen Laibow-Koser]

On Thu, May 16, 2019 at 6:06 PM Jahrme Risner <address@hidden> wrote:
[...]

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


My understanding is that MacTeX is basically the Mac packaging of TeXLive
(am I right about that?), and MacTeX *is* available on Homebrew, at least
as a cask.

But even if that weren’t true, it would still probably be possible to
install it on a Travis VM.  Travis makes using Homebrew especially easy,
but it is perfectly possible to install things in other ways in the Travis
environment.


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


That should not be necessary at all.


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


There is already a GitHub mirror of the LilyPond source, so this should be
no problem if I understand you correctly.

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.


AFAIK Travis is the only service of its kind that offers a hosted Mac build
environment free of charge for F/OSS projects.  That’s why I’m starting
with it.  If we have a suitable Mac environment elsewhere, great, but I’m
not assuming that we do.

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.


I’ll check out MacStadium, but my primary concern is to get a build server
set up *somewhere*.   I think Travis is the quickest and easiest way to do
that. If we then want to move it, it shouldn’t be too hard to do so.

[...]

> 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


 I understand why cross-compilation has been useful in the context of GUB,
but if we actually *can’t* build on the target OS, I would consider that to
be a broken build process.  I hope that’s not the case.

and there has been some
> more discussion on the preferred build/distribution work-flow going
> forward.


My intention is to find *some* solution that works and respects license
agreements.  Once we know what that is, we can figure out what a good
workflow for it would be.

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