On Wed, Oct 16, 2019 at 06:36, Marnen Laibow-Koser <mar...@marnen.org> wrote:
> On Tue, Oct 8, 2019 at 2:38 PM Marnen Laibow-Koser <mar...@marnen.org> > wrote: > > I’ve been playing around with the MacStadium environment and understanding > more about the build. Here’s what I think I know so far. Please correct > me if I’m wrong on any of this. > > * A straight compilation, by itself, won’t produce a suitable result. This > is because LilyPond depends on a bunch of dylibs that have to be installed > separately. The MacPorts mdmg approach palliates this to some extent, but > it seems to do so by producing an *installer* which installs the dylibs to > appropriate places in /opt or elsewhere. This is largely correct; nit, mpkg builds the installer which on modern macOS can be distributed as-is while mdmg wraps the installer built by mpkg as a dmg (disk image) which was necessary for distribution on very old versions of OSX. > * Better would be a single well-behaved .app bundle, so that no installer > is necessary. This is how Mac software is typically distributed, and it’s > how LilyPond has been distributed up to now. What would the “front-end” be? A .app bundle typically implies some kind of GUI interface, and my understanding is that the current suggestion is to use Frescobaldi if one needs an editor and does not already have a preferred text editor. We might be able to continue to ship the existing editor (if it was ported to python 3), however macOS is the only distribution handled this way. Also, I would argue that while .app bundles are *a* norm for distribution, software of a similar nature to LilyPond, like LaTeX, is typically installed using either a package manager or an installer (pkg). > * For that to work, the dylibs need to be moved into the .app bundle. > There are some tools like dylibbundler that might be able to automate this, > but the work has already been done in the GUB script that makes the 32-bit > Mac builds. Not directly related, but a consideration this comment reminded me of: to make these dylibs as portable as possible they must be built using as early of an sdk as possible. While we could choose to simply start supporting 64-bit at 10.15 (Catalina) and instruct users on 10.14 and below to use the x86 build, this would prevent users of earlier versions from reaping the benefits of the 64-bit build, namely the RAM limits. As such, a better build system might be OSX 10.8 (Mountain Lion) as this is the first version with a 64-but kernel and would allow any user who has updated since 2012 to run the application.This may present issues with MacStadium as I would be surprised if they made it easy to run arbitrary legacy versions of OSX. I know that MacPorts maintains a set of build machines running each version of OSX/macOS so whether we end up using them or not it might be worth reaching out to see what their system for producing builds is. > * That being the case, it seems (to my surprise) that the best course of > action would be to run GUB (with appropriate parameters and an appropriate > compiler) on Mac OS. Fortunately, this doesn’t look like it will be > anywhere near as difficult as I’d been led to believe: we’ve got Python and > a POSIX environment, so it looks like most of it will just work. Figuring > out the appropriate build options will probably be the biggest challenge. I admire your optimism! I contributed some work to GUB to get it running on macOS, though it was having many issues, and the one I was last blocked on, though I have not looked at for a while, is the inability to compile Perl through GUB on macOS. I‘ll try to take another look, though my work has shifted more towards improving the MacPorts distribution method as I feel that it is a more sustainable investment. > A question, BTW: I notice that the file gub/config_cache.py has loads of > ac_cv_* settings for each build target. I gather that these are Autoconf > config variables, and that I need to figure out the appropriate settings > for the 64-bit Mac build. Is there an automated way to do this (say, > through Autoconf itself), or do I just have to write a C program that calls > sizeof and so on to find out the values? (Sorry if this is a stupid > question; I’ve never messed around with Autoconf before.) I might be mistaken but I believe setting the ac_cv_* variables for x86_64-darwin might have been part of the changes I submitted, though as I’m away from my computer atm I cannot check. I hope I haven’t come across as being pessimistic or discouraging because I would really love for someone to solve the build/distribute problem. My main concerns right now are: how can we work to prevent issues like this biting us again (e.g., if Apple were to move macs off of Intel and onto custom ARM chips), how can we make the release process as painless as possible, and what path forward will work for the greatest portion of LilyPond users on macOS? For me, MacPorts (preferably as a package manager but with the mpkg fallback for those not wanting to use MacPorts) seems to tick the most boxes out of any of the suggestion I’ve heard. Thank you for your work on everything and for exploring MacStadium! Best, Jahrme > 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
