[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: macOS 64-bit

From: Marnen Laibow-Koser
Subject: Re: macOS 64-bit
Date: Thu, 16 May 2019 18:54:15 -0400

On Thu, May 16, 2019 at 6:39 PM David Kastrup <address@hidden> wrote:

> Marnen Laibow-Koser <address@hidden> writes:


> > Perhaps I don’t understand.  If GUB merely calls out to Xcode, how is
> this
> > a GPL3 issue?
> You would not be allowed to execute GUB on non-MacOSX hardware if using
> Xcode were an integral part of its operation, and this kind of
> restriction is not allowed by the GPLv3.

I’ll have to look more at how GUB works, but I think the idea that Xcode is
an “integral part” of GUB’s operation is at best arguable.  It looks to me
more like Xcode is one of a number of build tools that GUB could call if
it’s otherwise available on the system.

> How do you even imagine we could use Xcode on non-Mac hardware in the
> course of the release process?

I don’t.  As I said in my first post, my suggestion was to run GUB (or some
other suitable build runner) on a Travis Mac build environment or something
of that sort.

  Apple demands native compilation when
> using Xcode, and our release process does not run on Apple hardware.
> It's not like Jan as the author of GUB is out of the world and could be
> asked to license GUB in a manner where restraining its use to Apple
> hardware would be possible.

That is also good to know, although it wouldn’t be my first resort.
Anyway, that’s an issue for the GUB developer forum, not here.

(I note that Inkscape, which also uses GUB, is also having similar issues
with Mac packaging...)

> But I will not do so as LilyPond maintainer, and pressing for that kind
> of proprietary release process is outside of the resources the GNU
> project lends to LilyPond as GNU software.
> If Apple does not want software to be crosscompiled to MacOSX, that is
> their privilege.
> If you want to find a way around it, the way would likely be using some
> Darwin-only SDK.  We won't likely be able to include a GUI editor or GUI
> based install and it might impact some font inclusion details,

I don’t care about LilyPad very much, but I do care about handling Mac
fonts properly.  I also care about having an easily available binary
download, but that could probably be done without Xcode.

I have some other ideas about how this might be done without Xcode, but I
want to research their feasibility a little more before suggesting them.

but for
> the MacOSX GUI Apple clearly barrs us from using their current Xcode SDK
> in the release process using crosscompilation on GUB.

I think you *may* be conflating Xcode (the build tool, with hardware
restrictions) and the macOS SDK (the headers and such, without hardware


> --
> David Kastrup
Marnen Laibow-Koser address@hidden Sent from Gmail

reply via email to

[Prev in Thread] Current Thread [Next in Thread]