macOS 64-bit

classic Classic list List threaded Threaded
126 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

macOS 64-bit

Jahrme Risner
I want to preemptively apologize for the length of this email and give a TL;DR.

-----------------------------------------------------------------------------

TL;DR

I have been working on building a 64-bit macOS (x86_64-apple-darwin) release.

One option for build LilyPond for 64-bit macOS is Homebrew. Building LilyPond
with Homebrew has been met with partial success, but it is unclear whether the
ongoing work to make that method production ready would be worth the effort. My
full comments about working on Homebrew are at the bottom of this email.

In addition to Homebrew, I have also been looking at GUB and what I am
currently calling "macGUB". My explorations in GUB have already resulted in a
couple of patches, but there are further issues to resolve. "macGUB" is a very
early look at creating a macOS-specific build system that has as few
requirements beyond a clean install of macOS as possible. Comments on GUB and
macGUB follow below.

One final option which (for me) has met with failure is Nix. Nix is a
functional package manager (similar to GNU Guix) which allegedly works on
macOS. I was unable to get Nix to install correctly without extensive
troubleshooting (and even then it was rather brittle), so at this time, I
cannot suggest considering Nix as an official method for building or releasing
LilyPond for macOS. Further, the official Nix build farm has been unable to
successfully build LilyPond for macOS since 2017-08-15 so even with a smoother
installation there would be work necessary to make Nix viable.

-----------------------------------------------------------------------------

GUB

Currently, GUB has no knowledge of the x86_64-apple-darwin target. I have been
working on creating such a target (referred to as darwin-64 in GUB parlance).
This work has already resulted in two pull-requests to GUB so far with further
work yet to be submitted. Here are the two issues already resolved:

PR #61: Use generic Python database modules.
        https://github.com/gperciva/gub/pull/61
        This resolved an issue in the way the db python module was called which
        made GUB unusable on macOS as well as some Linux systems (Alpine Linux).

PR #62: Enable compiling librestrict on macOS.
        https://github.com/gperciva/gub/pull/62
        This change altered the way in which aliasing in librestrict was
        handled which made compiling librestrict possible on macOS

In addition to the pull request, I have also have work sitting on a branch that
is not yet ready for formal review, but if anyone else is interested can be
seen here:
    https://github.com/Jahrme/gub/tree/add_darwin-64

The current roadblock is Perl which will not compile on macOS. The log states
that the configuration script cannot find the standard c library and several
attempts to "point" the script to the library have been met with disappointment.

My current goal is to make GUB able to build the darwin-64 target on macOS, but
without the intent (yet) of enabling cross-compilation to darwin-64 from other
systems due to macOS SDK licensing issues. Once this has been achieved, the
next step would be to examine the offerings on
    https://opensource.apple.com
and hopefully be able to create the necessary portions of the SDK exclusively
from components explicitly release as open source by Apple.

If that is not possible, it may be that when releasing a new version of
LilyPond, either a contributor builds all release artifacts by running GUB on a
mac, or one contributor runs GUB on a mac to produce the mac-specific release
artifacts while a second contributor runs GUB on some other system to produce
all other targets.

In addition to this email I have some other thoughts more generally on GUB that
I am planning on sending shortly.

-----------------------------------------------------------------------------

macGUB

Right now I am (ball-parking it) perhaps 75% of the way to building LilyPond
from source on macOS with the only non-standard dependency being the Xcode
command line tools which are required by almost every other development tool
on macOS.

Currently I have two parallel implementations, one as a collection of
makefiles, the other as a python script compatible with macOS's system python.

In either case, these scripts recursively build the dependencies of LilyPond
from source which they download from the official release pages. This is slow
due to the time it takes some dependencies (e.g., gcc and glib) to compile.
While this is a non-optimal solution, it seems that as long as it was set up
carefully it may be a consistent way in which to specifically build on macOS.

My hope is that once macGUB can build LilyPond, it will at worst serve as one
way macOS users can get a 64-bit version of LilyPond, and hopefully would be an
option (barring getting GUB to work) to produce a (potentially unofficial) mac
release of LilyPond. Further, once the necessary flags/options for building on
macOS are understood, it may serve simply as a case-study on how to resolve
some of the GUB issues that currently prevent GUB from running on macOS.

-----------------------------------------------------------------------------

Homebrew (https://brew.sh) is a very commonly used package manager on macOS.

Within the last couple of years, Homebrew has chosen to completely remove all
tex-related content from their available packages. Along with the dependency on
guile@1.8, the dependency on programs provided through texlive was grounds for
the removal of LilyPond from Homebrew's packages.

The dependence on guile@1.8 may not be an issue anymore; I say may as Homebrew
requires ongoing security patch support from upstream for versioned packages,
and states that versioned packages should be "expected to be used by a large
number of people", see https://docs.brew.sh/Versions for more information.

The dependence on programs from texlive IS still an issue that requires awkward
workarounds that would definitely prevent LilyPond from being accepted into the
core set of packages.

For anyone who is interested in examining what I have done so far (or better-yet
would like to collaborate on finding a solution) I have uploaded my work to
    https://github.com/Jahrme/homebrew-lilypond.git
which includes instructions on using the Homebrew tap to install LilyPond.

I can currently build the stable release (2.18.2), but the development release
(2.19.83) fails out due to (I believe) a previously discovered issue with clang
involving template resolution. I have begun examining the possibility of having
gcc as a dependency to remove the clang issue, but I have not yet had success.

One further issue with the Homebrew build is that when running the Homebrew
audit tool, it complains about LilyPond's placement of Emacs Lisp files. The
full error message can be seen in the section below. I don't think this is a
pressing issue, but if Homebrew was used as a method of distributing LilyPond
it may be that providing an option to configure where the Emacs Lisp files are
placed would be a low-effort solution that would remove the error.

At this point I am unsure whether it is worth the effort to continue pursuing
Homebrew as a possible method of distributing LilyPond in its current form. As
I currently understand the dependencies, the texlive related dependencies are
necessary for building the font files used by LilyPond, so it may be possible
that if pre-compiled versions of the font files were available the texlive
issue could become a non-issue. In regards to guile@1.8, that might be solvable
by making it an internal dependency not (easily) accessible from outside of
LilyPond, however that may still be too much of a stretch for getting LilyPond
into mainline Homebrew. Either way, it is also possible (as I did) to provide
LilyPond through Homebrew without it having to be added into the main repo; the
main issue with creating a tap instead of having LilyPond officially added is
that when users use the brew search function the tap will not be shown unless
the user has previously added the tap.

Any comments for, against, or otherwise related to pursuing a Homebrew release
are welcome.

-----------------------------------------------------------------------------

Homebrew Audit Error

lilypond:
  * Emacs Lisp files were linked directly to /usr/local/share/emacs/site-lisp
    This may cause conflicts with other packages.
    They should instead be installed into:
    /usr/local/opt/lilypond/share/emacs/site-lisp/lilypond

    The offending files are:
        /usr/local/opt/lilypond/share/emacs/site-lisp/lilypond-what-beat.el
        /usr/local/opt/lilypond/share/emacs/site-lisp/lilypond-words.el
        /usr/local/opt/lilypond/share/emacs/site-lisp/lilypond-song.el
        /usr/local/opt/lilypond/share/emacs/site-lisp/lilypond-font-lock.el
        /usr/local/opt/lilypond/share/emacs/site-lisp/lilypond-init.el
        /usr/local/opt/lilypond/share/emacs/site-lisp/lilypond-indent.el
        /usr/local/opt/lilypond/share/emacs/site-lisp/lilypond-mode.el
Error: 1 problem in 1 formula detected

-----------------------------------------------------------------------------

Again, sorry for the length of the email!

Best wishes,

Jahrme

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

Karlin High
On 4/5/2019 5:41 PM, Jahrme Risner wrote:
> next step would be to examine the offerings on
>      https://opensource.apple.com
> and hopefully be able to create the necessary portions of the SDK exclusively
> from components explicitly release as open source by Apple.

That's exactly what I was thinking, too. I've collected a list of
cross-compile projects and was reviewing their methods and requirements,
looking for a way to have Linux build a "hello world" command-line
executable for macOS without running afoul of either GNU or Apple licensing.

Some Apple Open Source things are GPL2 license, and some are Apple
Public Software License. The Free Software Foundation's review of the
APSL states a preference for the 2.0 version, which they apparently
influenced.

"
We encourage everyone who uses any version of Apple Software under the
APSL to use the terms of version 2.0 rather than that of any earlier
license...

...we recommend you do not release new software using this license; but
it is ok to use and improve software which other people release under
this license.
"
<https://www.gnu.org/philosophy/apsl.html>

For broadest compatibility, I was looking for the oldest components that
could produce working software for the newest macOS and have the APSL
2.0 terms. But I hadn't got very far yet. I gather you can offer more
skill and capacity for this than I currently can.
--
Karlin High
Missouri, USA

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

Werner LEMBERG
In reply to this post by Jahrme Risner

> I have been working on building a 64-bit macOS (x86_64-apple-darwin)
> release.

Very nice!  And thanks for your very detailed e-mail.

> One option for build LilyPond for 64-bit macOS is Homebrew. Building
> LilyPond with Homebrew has been met with partial success, but it is
> unclear whether the ongoing work to make that method production
> ready would be worth the effort.  My full comments about working on
> Homebrew are at the bottom of this email.

I suggest to drop Homebrew in favour of MacPorts.  On first sight
Homebrew is much more `shiny', certainly appealing young, dynamic
users.  However, its decision to only support a very small set of
features and macOS releases makes it very `apple-y' in a bad sense
IMHO.

Not having time yet to explore this further, MacPorts allows the
building of packages that can be installed and executed stand-alone,
see

  https://lists.gnu.org/archive/html/lilypond-devel/2019-03/msg00041.html
  https://lists.macports.org/pipermail/macports-users/2019-March/046530.html

and follow-ups.  By streamlining MacPorts's `Portfile' for
`lilypond-devel' it should be possible to reduce the number of
dependencies a lot, possibly leading to something useful.

  https://github.com/macports/macports-ports/tree/master/textproc/lilypond-devel

> In addition to the pull request, I have also have work sitting on a
> branch that is not yet ready for formal review, but if anyone else
> is interested can be seen here:
>
>   https://github.com/Jahrme/gub/tree/add_darwin-64

I think all of those patches can be already added to GUB.  Please
provide one or more pull requests.

> The current roadblock is Perl which will not compile on macOS. The
> log states that the configuration script cannot find the standard c
> library and several attempts to "point" the script to the library
> have been met with disappointment.

Perhaps it makes sense to look how MacPorts does it?

  https://github.com/macports/macports-ports/blob/master/lang/perl5

BTW, Mojca is on the lilypond list, too – maybe she can assist.


    Werner
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

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


Werner LEMBERG wrote

>> I have been working on building a 64-bit macOS (x86_64-apple-darwin)
>> release.
>
> Very nice!  And thanks for your very detailed e-mail.
>
>> One option for build LilyPond for 64-bit macOS is Homebrew. Building
>> LilyPond with Homebrew has been met with partial success, but it is
>> unclear whether the ongoing work to make that method production
>> ready would be worth the effort.  My full comments about working on
>> Homebrew are at the bottom of this email.
>
> I suggest to drop Homebrew in favour of MacPorts.  On first sight
> Homebrew is much more `shiny', certainly appealing young, dynamic
> users.  However, its decision to only support a very small set of
> features and macOS releases makes it very `apple-y' in a bad sense
> IMHO.

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.

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.

However, I don't think we have to force people to use it.  Read on.


>> In addition to the pull request, I have also have work sitting on a
>> branch that is not yet ready for formal review, but if anyone else
>> is interested can be seen here:
>>
>>   https://github.com/Jahrme/gub/tree/add_darwin-64
>
> I think all of those patches can be already added to GUB.  Please
> provide one or more pull requests.

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.

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?

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.

Best,
--
Marnen E. Laibow-Koser
[hidden email]
http://www.marnen.org




--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

David Kastrup
marnen <[hidden email]> writes:

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

The GPL 3.0 does not allow additional restrictions such as requiring
certain hardware.  Availability is not an issue, the restrictions are.

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

This is not a problem of abilities but of permissions.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

marnen
On Thu, May 16, 2019 at 5:01 PM David Kastrup <[hidden email]> wrote:

> marnen <[hidden email]> writes:
>
> > 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.
>
> The GPL 3.0 does not allow additional restrictions such as requiring
> certain hardware.  Availability is not an issue, the restrictions are.
>
[...]

Xcode is not governed by GPL3, and AFAIK it's the only component at issue
here whose license stipulates particular hardware.  As far as I can tell
from the license agreement at
https://www.apple.com/legal/sla/docs/xcode.pdf (same
version as in my copy of Xcode 10.2.1) , this restriction does not apply to
binaries built with Xcode.

§2.2 of the license agreement, in fact, specifically *exempts* the macOS
SDK from the Apple-branded hardware restriction, so that even that is not a
concern.

So my reading of the Xcode license is that there is no Apple hardware
restriction for a Mac application built with Xcode (things may be different
for iOS, but that's not what we're discussing here).  In that case, as long
as the Xcode build itself is run on Apple hardware, there should be no
legal obstacle in building a Mac application with Xcode for distribution
under GPL3. And in fact, there *do* exist Mac GUI applications (such as
Cyberduck, https://g.iterate.ch/scm/iterate/cyberduck.git ) that are
distributed under GPL3 and built with Xcode, for whatever that's worth.


> --
> David Kastrup
>

Best,
--
Marnen Laibow-Koser
[hidden email]
http://www.marnen.org
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

marnen
On Thu, May 16, 2019 at 5:48 PM Marnen Laibow-Koser <[hidden email]>
wrote:
[...]

> And in fact, there *do* exist Mac GUI applications (such as Cyberduck,
> https://g.iterate.ch/scm/iterate/cyberduck.git ) that are distributed
> under GPL3 and built with Xcode, for whatever that's worth.
>

I meant to say *64-bit* Mac GUI applications. :)

Best,
--
Marnen Laibow-Koser
[hidden email]
http://www.marnen.org
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

Jahrme Risner
In reply to this post by marnen
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

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

publickey - lilypond@jahrme.com - 0x307E3DA6.asc (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

Hans Åberg-2

> On 17 May 2019, at 00:06, Jahrme Risner <[hidden email]> wrote:
>
> There is not, AFAIK, *any* elegant
> solution to the usage of texlive on macOS.

TeXLive is in MacPorts, and one can choose the components. Also, one can have different installers for the program and docs and merge the stuff.



_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

David Kastrup
In reply to this post by marnen
Marnen Laibow-Koser <[hidden email]> writes:

> On Thu, May 16, 2019 at 5:01 PM David Kastrup <[hidden email]> wrote:
>
>> marnen <[hidden email]> writes:
>>
>> > 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.
>>
>> The GPL 3.0 does not allow additional restrictions such as requiring
>> certain hardware.  Availability is not an issue, the restrictions are.
>>
> [...]
>
> Xcode is not governed by GPL3, and AFAIK it's the only component at issue
> here whose license stipulates particular hardware.

GUB is governed by the GPLv3.  Nobody claims that people may not
independently create ports of LilyPond for MacOSX but creating them as
part of GUB in the general release process is not an option with the
current Xcode license.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

marnen
On Thu, May 16, 2019 at 6:22 PM David Kastrup <[hidden email]> wrote:

> Marnen Laibow-Koser <[hidden email]> writes:
>
> > On Thu, May 16, 2019 at 5:01 PM David Kastrup <[hidden email]> wrote:
> >
> >> marnen <[hidden email]> writes:
> >>
> >> > 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.
> >>
> >> The GPL 3.0 does not allow additional restrictions such as requiring
> >> certain hardware.  Availability is not an issue, the restrictions are.
> >>
> > [...]
> >
> > Xcode is not governed by GPL3, and AFAIK it's the only component at issue
> > here whose license stipulates particular hardware.
>
> GUB is governed by the GPLv3.  Nobody claims that people may not
> independently create ports of LilyPond for MacOSX but creating them as
> part of GUB in the general release process is not an option with the
> current Xcode license.


Perhaps I don’t understand.  If GUB merely calls out to Xcode, how is this
a GPL3 issue?


>
> --
> David Kastrup
>
--
Marnen Laibow-Koser [hidden email] http://www.marnen.org Sent from Gmail
Mobile
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

David Kastrup
In reply to this post by Jahrme Risner
Jahrme Risner <[hidden email]> writes:

> Hello Marnen,
>
>> 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.

No, it means that is prohibited by Apple to use Xcode for compiling
LilyPond with GUB on non-Apple hardware.  This is a restriction
incompatible with the GPLv3 license GUB is under, so current Xcode
versions cannot be made a part of GUB.

It does not preclude someone else compiling LilyPond with Xcode under
whatever native platform they want, but it means that MacOSX compilation
cannot be integrated into GUB and consequently our release process using
the current Xcode SDK.

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

We build our Windows binaries with GUB and upload them essentially
untested.  That may seem surprising, but once stuff makes it through
GUB, it is quite rare that it is inoperative to any significant degree.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

David Kastrup
In reply to this post by marnen
Marnen Laibow-Koser <[hidden email]> writes:

> On Thu, May 16, 2019 at 6:22 PM David Kastrup <[hidden email]> wrote:
>
>> Marnen Laibow-Koser <[hidden email]> writes:
>>
>> > On Thu, May 16, 2019 at 5:01 PM David Kastrup <[hidden email]> wrote:
>> >
>> >> marnen <[hidden email]> writes:
>> >>
>> >> > 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.
>> >>
>> >> The GPL 3.0 does not allow additional restrictions such as requiring
>> >> certain hardware.  Availability is not an issue, the restrictions are.
>> >>
>> > [...]
>> >
>> > Xcode is not governed by GPL3, and AFAIK it's the only component at issue
>> > here whose license stipulates particular hardware.
>>
>> GUB is governed by the GPLv3.  Nobody claims that people may not
>> independently create ports of LilyPond for MacOSX but creating them as
>> part of GUB in the general release process is not an option with the
>> current Xcode license.
>
> 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.

How do you even imagine we could use Xcode on non-Mac hardware in the
course of the release process?  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.

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, but for
the MacOSX GUI Apple clearly barrs us from using their current Xcode SDK
in the release process using crosscompilation on GUB.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

Hans Åberg
In reply to this post by marnen

> On 17 May 2019, at 00:26, Marnen Laibow-Koser <[hidden email]> wrote:
>
> Perhaps I don’t understand.  If GUB merely calls out to Xcode, how is this
> a GPL3 issue?

One needs to extract the SDK, and that has only been done for an old XCode version that is 32-bit, so it wouldn’t help anyway.



_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

marnen
In reply to this post by David Kastrup
On Thu, May 16, 2019 at 6:39 PM David Kastrup <[hidden email]> wrote:

> Marnen Laibow-Koser <[hidden email]> 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
restrictions).

>


>
> --
> David Kastrup
>
Best,
--
Marnen Laibow-Koser [hidden email] http://www.marnen.org Sent from Gmail
Mobile
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

Jahrme Risner
In reply to this post by David Kastrup
On Thu, May 16, 2019 at 15:39, David Kastrup <[hidden email]> wrote

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

The way I had been approaching an addition of 64-bit Darwin to GUB was that, due to the Xcode restrictions, on non-Apple hardware GUB would compile all non-Darwin targets and simply ignore requests for Darwin targets, perhaps with a warning. In order to produce a Darwin release, someone would need to install GUB on a Mac and run the Darwin build from there. This would mean that Darwin binaries might lag behind other architectures until someone with a Mac could get around to producing a build.

To my understanding this is no different than an application *providing* GPU acceleration capabilities but not requiring it; it does not mean that someone without a GPU cannot run the software, just that they are not using features irrelevant to their hardware. We would be *providing* the option to build Darwin *if* on a Mac, not requiring a Mac for GUB to run.

If this is still too much of an ask then perhaps I am missing some finer point.
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

marnen
In reply to this post by marnen
On Thu, May 16, 2019 at 6:54 PM Marnen Laibow-Koser <[hidden email]>
wrote:

>
>
> On Thu, May 16, 2019 at 6:39 PM David Kastrup <[hidden email]> wrote:
>
[...]

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

...or not.  On rereading the license agreement, I see that there are
hardware restrictions on the SDK that had escaped my notice initially.

Back to the drawing board on that idea, then.  Running GUB, or at least the
Mac build script, on a Travis Mac is starting to look like a better and
better idea for a 64-bit Mac build.  But I’ll keep thinking.

Best,
--
Marnen Laibow-Koser [hidden email] http://www.marnen.org Sent from Gmail
Mobile
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

Werner LEMBERG
In reply to this post by marnen

>>> One option for build LilyPond for 64-bit macOS is Homebrew.
>>> Building LilyPond with Homebrew has been met with partial success,
>>> but it is unclear whether the ongoing work to make that method
>>> production ready would be worth the effort.  My full comments
>>> about working on Homebrew are at the bottom of this email.
>>
>> I suggest to drop Homebrew in favour of MacPorts.  On first sight
>> Homebrew is much more `shiny', certainly appealing young, dynamic
>> users.  However, its decision to only support a very small set of
>> features and macOS releases makes it very `apple-y' in a bad sense
>> IMHO.
>
> 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.

Given that MacPorts supports more packages than Homebrew this is a
very bold statement.  And all users that don't use the two latest
releases of MacOS (like me) are out of the game, too.

[Note that I'm not a MacOS user at all.  For daily work I'm
 exclusively using GNU/Linux.  It's just that I'm interested in
 providing support even on exotic platforms :-)]

> For myself, I hate MacPorts so much that if LilyPond came to require
> MacPorts, [...]

Just wondering: What's the reason for this?

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

There is a fundamental misunderstanding.  Nobody is *forced* to use
MacPorts!  LilyPond doesn't depend on it.  Homebrew itself doesn't
contain lilypond-dev; you rather have to use a private cask instead,
for example

  https://github.com/Homebrew/homebrew-cask-versions/blob/master/Casks/lilypond-dev.rb

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

It would be really great if you can assist in providing a 64bit Mac
binary that doesn't violate any licences, and we are more than happy
if you have success.


    Werner

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

marnen
On Fri, May 17, 2019 at 1:33 AM Werner LEMBERG <[hidden email]> wrote:

> > 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.
>
> Given that MacPorts supports more packages than Homebrew this is a
> very bold statement.


Homebrew supports enough packages, and it’s really easy to add new ones, so
that’s pretty much irrelevant.  (I used to maintain the Homebrew
Frescobaldi package, before there were Mac binaries available.)


And all users that don't use the two latest
> releases of MacOS (like me) are out of the game, too.
>
> [Note that I'm not a MacOS user at all.  For daily work I'm
>  exclusively using GNU/Linux.  It's just that I'm interested in
>  providing support even on exotic platforms :-)]


Since you’re not a Mac user, are you in any position to talk about what’s
more usable on Mac OS *to experienced Mac users*?

I use Mac OS as my primary platform, FWIW.


>
> > For myself, I hate MacPorts so much that if LilyPond came to require
> > MacPorts, [...]
>
> Just wondering: What's the reason for this?


It’s been a long time since I used MacPorts, so my recollections are hazy.
But as far as I recall, it puts a lot of duplicated crap on the computer,
the CLI was needlessly complicated compared to Fink or Homebrew, and
virtually every interaction with it annoyed me.  Perhaps they’ve fixed
these issues, but since it kind of wants to take over the world, it’s hard
for me to test it again and get rid of it if I don’t like it.  (I suppose I
could use a VM.)

Also, since I already use Homebrew extensively, I’d rather avoid installing
a parallel piece of software with a parallel package tree.

If you’re not a Mac user, I suppose it makes sense that you’d prefer
MacPorts: isn’t it more or less a BSD package manager?  The problem,
though, is that it doesn’t fit the spirit of Mac OS very well.  Homebrew
does a *much* better job at playing nice with the rest of the OS, its CLI
is pleasant, and it’s easy to create new packages.


>
> > 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.
>
> There is a fundamental misunderstanding.  Nobody is *forced* to use
> MacPorts!  LilyPond doesn't depend on it.


If the alternative is manually downloading all the dependencies and
building manually, then a package manager is nearly essential for a complex
program like LilyPond. :)

(For myself, even with Homebrew installed, I’d rather download a binary
than build from source anyway, though I will do the latter when it makes
sense.)

Homebrew itself doesn't
> contain lilypond-dev; you rather have to use a private cask instead,
> for example
>
>
> https://github.com/Homebrew/homebrew-cask-versions/blob/master/Casks/lilypond-dev.rb


I’m not sure how this is relevant.  And it wouldn’t be hard to make the
cask public if wanted.

<https://github.com/Homebrew/homebrew-cask-versions/blob/master/Casks/lilypond-dev.rb>
>
> > [...] 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.
>
> It would be really great if you can assist in providing a 64bit Mac
> binary that doesn't violate any licences, and we are more than happy
> if you have success.


I intend to try if no one has come up with a better solution by then.  It’s
important to me to keep Mac binaries available.

A lot of the natural users for LilyPond are composers.  Many of them are
not very technical and won’t want to install a package manager when they
can get MuseScore, Finale, Sibelius, or Noteflight without that extra
step.  That’s one reason that I think it’s important to lower the bar to
getting a binary as much as possible.


>
>
>     Werner
>
Best,
--
Marnen Laibow-Koser [hidden email] http://www.marnen.org Sent from Gmail
Mobile
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

Werner LEMBERG

>> And all users that don't use the two latest releases of MacOS (like
>> me) are out of the game, too.
>>
>> [Note that I'm not a MacOS user at all.  For daily work I'm
>>  exclusively using GNU/Linux.  It's just that I'm interested in
>>  providing support even on exotic platforms :-)]
>
> Since you’re not a Mac user, are you in any position to talk about
> what’s more usable on Mac OS *to experienced Mac users*?

Uh, oh, a smiley in the end seems not to be enough to mark irony...

Irrespective of that, Homebrew does not support macOS 10.7, so this is
not related to `experience' at all.

> If you’re not a Mac user, I suppose it makes sense that you’d prefer
> MacPorts: isn’t it more or less a BSD package manager?  The problem,
> though, is that it doesn’t fit the spirit of Mac OS very well.
> Homebrew does a *much* better job at playing nice with the rest of
> the OS, its CLI is pleasant, and it’s easy to create new packages.

I started with Homebrew, but since 10.7 is no longer supported I was
forced to abandon it.  By the way, it seems to me that your `hazy
recollections' are no longer valid, as far as I can tell.  Having used
both package managers I don't see an essential difference in the CLI
(except that Homebrew uses colours and the sexy beer emoji on the
command line).

> A lot of the natural users for LilyPond are composers.  Many of them
> are not very technical and won’t want to install a package manager
> when they can get MuseScore, Finale, Sibelius, or Noteflight without
> that extra step.  That’s one reason that I think it’s important to
> lower the bar to getting a binary as much as possible.

Agreed.


    Werner
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
1234 ... 7