Re: macOS 64-bit
>>> 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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
On Thu, May 16, 2019 at 6:54 PM Marnen Laibow-Koser wrote: > > > On Thu, May 16, 2019 at 6:39 PM David Kastrup 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 mar...@marnen.org http://www.marnen.org Sent from Gmail Mobile ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
On Thu, May 16, 2019 at 15:39, David Kastrup 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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
On Thu, May 16, 2019 at 6:39 PM David Kastrup wrote: > Marnen Laibow-Koser 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 mar...@marnen.org http://www.marnen.org Sent from Gmail Mobile ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
> On 17 May 2019, at 00:26, Marnen Laibow-Koser 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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
Marnen Laibow-Koser writes: > On Thu, May 16, 2019 at 6:22 PM David Kastrup wrote: > >> Marnen Laibow-Koser writes: >> >> > On Thu, May 16, 2019 at 5:01 PM David Kastrup wrote: >> > >> >> marnen 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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
Jahrme Risner 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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
On Thu, May 16, 2019 at 6:22 PM David Kastrup wrote: > Marnen Laibow-Koser writes: > > > On Thu, May 16, 2019 at 5:01 PM David Kastrup wrote: > > > >> marnen 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 mar...@marnen.org http://www.marnen.org Sent from Gmail Mobile ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
> On 17 May 2019, at 00:06, Jahrme Risner 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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
Marnen Laibow-Koser writes: > On Thu, May 16, 2019 at 5:01 PM David Kastrup wrote: > >> marnen 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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
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 complexi
Re: macOS 64-bit
On Thu, May 16, 2019 at 5:48 PM Marnen Laibow-Koser 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 mar...@marnen.org http://www.marnen.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
On Thu, May 16, 2019 at 5:01 PM David Kastrup wrote: > marnen 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 mar...@marnen.org http://www.marnen.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
marnen 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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
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 mar...@marnen.org http://www.marnen.org -- Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
