macOS 64-bit

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

Re: macOS 64-bit

marnen
On Tue, Oct 8, 2019 at 2:38 PM Marnen Laibow-Koser <[hidden email]>
wrote:

> Update: with wedding stuff, I haven’t had time to devote to this, but with
> Mac OS Catalina coming out this has become more urgent, as Catalina removes
> 32-bit support altogether.  I’m gonna try to spend some time on this in the
> next few days, and would welcome help from anyone interested.  I’ll post
> info for the MacStadium environment once I set it up.
>

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.

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

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

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

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

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
On Wed, Oct 16, 2019 at 06:36, Marnen Laibow-Koser <[hidden email]> wrote:

> On Tue, Oct 8, 2019 at 2:38 PM Marnen Laibow-Koser <[hidden email]>
> 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 [hidden email] http://www.marnen.org Sent from Gmail
> Mobile
> _______________________________________________
> lilypond-devel mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
_______________________________________________
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 Wed, Oct 16, 2019 at 4:23 PM Jahrme Risner <[hidden email]> wrote:

>
>
> On Wed, Oct 16, 2019 at 06:36, Marnen Laibow-Koser <[hidden email]>
> wrote:
>
> On Tue, Oct 8, 2019 at 2:38 PM Marnen Laibow-Koser <[hidden email]>
> wrote:
>
> [...]

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

I think I was aware of that.  :) Thanks for the clarification.


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


Lilypad has been adequate for this up to now.

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.


And that would be my suggestion too.


We might be able to continue to ship the existing editor (if it was ported
> to python 3),


What does Python 3 have to do with it?  (I haven’t looked at the Lilypad
code yet.)

however macOS is the only distribution handled this way.


Understood.  I think that this approach still makes sense.


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

LaTeX is mostly used by technical people.  I’d venture to guess that most
of LilyPond’s target users on Mac OS have never even *heard* of a package
manager.  Besides, LilyPond has a lot of runtime dependencies, and an .app
bundle corrals them all nicely.

Also, the closest alternatives to LilyPond are MuseScore, Finale, Sibelius,
and so on.  None requires a package manager to install on Mac OS.  Neither
does Frescobaldi, for that matter.  Neither should LilyPond, if we want
nontechnical folks to use it.

In a perfect world, the app bundle would contain a *decent* editor. :)
Maybe Frescobaldi.  But that’s beyond the scope of this particular
project.  I just want to get *something* working.

[...]

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


Prepare to be surprised, then! :) The MacStadium box is running Yosemite
(10.10), which was the oldest version I could easily get, for precisely
this reason.  But it’s also no big deal: older versions of Mac OS can still
use the 32-bit builds from the Linux GUB instance, right?


>
> * 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’m currently working on that, building on your existing work.  It looks
like some of GUB’s build flags for Perl are just plain *st00pid* on Mac OS,
and so I plan to modify or disable them for a Darwin build environment.

This process has far too much yak shaving.  The fact that GUB is necessary
suggests that LilyPond’s build process is more complex than it needs to
be...



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

As long as it doesn’t force the end user into installing MacPorts itself.


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

Yeah, I found your pull request and I’m currently using that as part of my
branch.  Thanks!


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

I think I’m fairly close.  We’ll see if I’m right. :)

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),
>

By building on the target platform like nearly everyone else does. :)  A
system like GUB should IMHO be a supplement to native builds, not a
replacement for them.

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

I’m mystified by the love for MacPorts that I’ve heard from you and others
in this group.  It’s got some advantages on a build box, but I don’t know
*anyone* these days, outside of this group, who uses it on an end-user
machine.  In the communities I’m familiar with, everyone uses Homebrew if
they use a package manager at all, and it’s been this way for years.

Maybe *you* find MacPorts preferable, but that view doesn’t reflect that of
the majority of the end users I’ve run into.

Anyway, glad to hear that you’ll be thinking of the mpkg approach.  I
suspect if the project goes that route, the majority of users would take
that option.  I know I would.


> Thank you for your work on everything and for exploring MacStadium!
>

And thanks for your contributions!


> Best,
> Jahrme
>

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 Jahrme Risner

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

I have a 64bit Mac OS 10.7.5 machine at home; theoretically, this
should do the compilation job too, right?  Note, however, that I don't
use this machine except for testing software (mostly the
`lilypond-devel' bundle from MacPorts).  In particular, I have zero
experience with Mac programming...


    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

Hans Åberg-2

> On 17 Oct 2019, at 09:21, Werner LEMBERG <[hidden email]> wrote:
>
> I have a 64bit Mac OS 10.7.5 machine at home;

I made an installer into /opt/lilypond/ on MacOS 10.15, which you might try out.

> theoretically, this
> should do the compilation job too, right?

It takes a very long time to do it as one has to do a new MacPorts installation and compile all from scratch.


_______________________________________________
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, Oct 17, 2019 at 6:24 PM Hans Åberg <[hidden email]> wrote:

>
> > On 17 Oct 2019, at 09:21, Werner LEMBERG <[hidden email]> wrote:
> >
> > I have a 64bit Mac OS 10.7.5 machine at home;


Thanks, but I tend to think that the build box shouldn’t be anyone’s
personal machine if that’s possible.  (Once I get the MacStadium machine
building LilyPond reliably, I intend to give control of it to the core
team.)


>
> I made an installer into /opt/lilypond/ on MacOS 10.15, which you might
> try out.


With port mdmg/mpkg, or some other way?

How do I try this out?


>
> > theoretically, this
> > should do the compilation job too, right?
>
> It takes a very long time to do it as one has to do a new MacPorts
> installation and compile all from scratch.
>

Yeah, I was experimenting with this too.

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

Hans Åberg-2


> On 18 Oct 2019, at 00:30, Marnen Laibow-Koser <[hidden email]> wrote:
>
> On Thu, Oct 17, 2019 at 6:24 PM Hans Åberg <[hidden email]> wrote:
>
>> I made an installer into /opt/lilypond/ on MacOS 10.15, which you might
>> try out.
>
>
> With port mdmg/mpkg, or some other way?

Yes, see
https://lists.gnu.org/archive/html/lilypond-devel/2019-03/msg00065.html

> How do I try this out?

Try this link:
https://web2.storegate.com/share/oCQjV4r



_______________________________________________
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, Oct 17, 2019 at 6:52 PM Hans Åberg <[hidden email]> wrote:

>
>
> > On 18 Oct 2019, at 00:30, Marnen Laibow-Koser <[hidden email]> wrote:
> >
> > On Thu, Oct 17, 2019 at 6:24 PM Hans Åberg <[hidden email]> wrote:
> >
> >> I made an installer into /opt/lilypond/ on MacOS 10.15, which you might
> >> try out.
> >
> >
> > With port mdmg/mpkg, or some other way?
>
> Yes, see
> https://lists.gnu.org/archive/html/lilypond-devel/2019-03/msg00065.html
>
> > How do I try this out?
>
> Try this link:
> https://web2.storegate.com/share/oCQjV4r
>

Awesome, thanks; I’ll try it when I get a chance. I still want to get an
.app bundle built, but it’s good to know that the mdmg approach actually
works as advertised. :)

>
>
> --
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
On Thu, Oct 17, 2019 at 19:08, Marnen Laibow-Koser <[hidden email]> wrote:

> Awesome, thanks; I’ll try it when I get a chance. I still want to get an .app bundle built, but it’s good to know that the mdmg approach actually works as advertised. :)

If you would like to see for yourself how the MacPorts build works, I have included a script to automate the entire process. I haven’t tested it in the last couple weeks (currently I’m away from my Mac), but I’m not aware of anything that should have changed.

I would actually be quite interested in how long it takes on the MacStadium image. I have also been toying with the idea of trying to get some automated builds created using Tavis CI, but haven’t had time what with a new job and moving, plus I think as it is now it might not fall into the allotted time for free builds.

Script:

#!/bin/sh

ly_version=2.19.83

mp_version=2.6.1

install_dir=/opt/lilypond/${ly_version}

mp_url=https://distfiles.macports.org/MacPorts/MacPorts-${mp_version}.tar.bz2

##################################

# Download and install macports. #

##################################

export PATH=/bin:/sbin:/usr/bin:/usr/sbin

curl -L -s ${mp_url} | tar xf -

cd MacPorts-${mp_version}

./configure --without-startupitems --prefix=${install_dir} --with-applications-dir=${install_dir}/Applications

make

sudo make install

#################################

# Build the metapackage (.mkpg) #

#################################

export PATH=/bin:/sbin:/usr/bin:/usr/sbin:${install_dir}/bin

sudo port -N selfupdate

sudo port -N mpkg lilypond-devel
_______________________________________________
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 Sat, Oct 19, 2019 at 11:30 AM Jahrme Risner <[hidden email]> wrote:

> On Thu, Oct 17, 2019 at 19:08, Marnen Laibow-Koser <[hidden email]>
> wrote:
>
> Awesome, thanks; I’ll try it when I get a chance. I still want to get an
> .app bundle built, but it’s good to know that the mdmg approach actually
> works as advertised. :)
>
> If you would like to see for yourself how the MacPorts build works, I have
> included a script to automate the entire process. I haven’t tested it in
> the last couple weeks (currently I’m away from my Mac), but I’m not aware
> of anything that should have changed.


Good to know.  Thanks.

>
> I would actually be quite interested in how long it takes on the
> MacStadium image.
>

I may try it there at some point, but right now I’m focusing on GUB
dependencies.  I got Perl to build; right now I’m working with GNU file,
which isn’t finding libz1.2.3 in the right place.  (Anyone know how to
massage the library flags to get this to work?)

I have also been toying with the idea of trying to get some automated
> builds created using Tavis CI, but haven’t had time what with a new job and
> moving, plus I think as it is now it might not fall into the allotted time
> for free builds.
>

That was my experience with the Travis instance I set up.  It’s attached to
the GitHub LilyPond mirror, and you can look at the build history.

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

Hans Åberg-2
In reply to this post by Jahrme Risner

> On 19 Oct 2019, at 17:30, Jahrme Risner <[hidden email]> wrote:
>
> On Thu, Oct 17, 2019 at 19:08, Marnen Laibow-Koser <[hidden email]> wrote:
>
>> Awesome, thanks; I’ll try it when I get a chance. I still want to get an .app bundle built, but it’s good to know that the mdmg approach actually works as advertised. :)
>
> If you would like to see for yourself how the MacPorts build works, I have included a script to automate the entire process. I haven’t tested it in the last couple weeks (currently I’m away from my Mac), but I’m not aware of anything that should have changed.
>
> I would actually be quite interested in how long it takes on the MacStadium image. I have also been toying with the idea of trying to get some automated builds created using Tavis CI, but haven’t had time what with a new job and moving, plus I think as it is now it might not fall into the allotted time for free builds.

As port knows how to use full paths, it suffices to use ${install_dir}/port to selfupdate and mpkg on; then the export PATH seems unnecessary. In addition, more than one selfupdate may be required.  Otherwise, normally the local path should be ahead of the system paths, making sure to override the typically older system software.

> Script:
>
> #!/bin/sh



_______________________________________________
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 Sat, Oct 19, 2019 at 11:33 AM Marnen Laibow-Koser <[hidden email]>
wrote:
[...]

> I may try it there at some point, but right now I’m focusing on GUB
> dependencies.  I got Perl to build; right now I’m working with GNU file,
> which isn’t finding libz1.2.3 in the right place.  (Anyone know how to
> massage the library flags to get this to work?)
>

Update: I managed to get all the generic *nix GUB dependencies building on
the MacStadium box.  Now I'm into the Darwin-specific ones...and of course
it *assumes* that it's cross-compiling them, which causes some problems.
Before I spend too much time looking aimlessly: does anyone know where in
the GUB source code it figures out if it's cross-compiling?  I think I may
need to change the logic there, and I'm not sure where to find it.  I'll
find it eventually, of course, but if anyone can point me to the right
place, it would make the process go faster.

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 Sat, Oct 19, 2019 at 1:15 PM Marnen Laibow-Koser <[hidden email]>
wrote:

>
>
> On Sat, Oct 19, 2019 at 11:33 AM Marnen Laibow-Koser <[hidden email]>
> wrote:
> [...]
>
>> I may try it there at some point, but right now I’m focusing on GUB
>> dependencies.  I got Perl to build; right now I’m working with GNU file,
>> which isn’t finding libz1.2.3 in the right place.  (Anyone know how to
>> massage the library flags to get this to work?)
>>
>
> Update: I managed to get all the generic *nix GUB dependencies building on
> the MacStadium box.  Now I'm into the Darwin-specific ones...and of course
> it *assumes* that it's cross-compiling them, which causes some problems.
> Before I spend too much time looking aimlessly: does anyone know where in
> the GUB source code it figures out if it's cross-compiling?  I think I may
> need to change the logic there, and I'm not sure where to find it.  I'll
> find it eventually, of course, but if anyone can point me to the right
> place, it would make the process go faster.
>

Further update: I've had a look through as much of the GUB source code as
seemed relevant, and I can't for the life of me figure out where it
determines if it's cross-compiling.  I think I need a bit of help here from
someone who understands better how GUB works.

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 Sun, Oct 20, 2019 at 5:19 PM Marnen Laibow-Koser <[hidden email]>
wrote:

> On Sat, Oct 19, 2019 at 1:15 PM Marnen Laibow-Koser <[hidden email]>
> wrote:
>
>>
>>
>> On Sat, Oct 19, 2019 at 11:33 AM Marnen Laibow-Koser <[hidden email]>
>> wrote:
>> [...]
>>
>>> I may try it there at some point, but right now I’m focusing on GUB
>>> dependencies.  I got Perl to build; right now I’m working with GNU file,
>>> which isn’t finding libz1.2.3 in the right place.  (Anyone know how to
>>> massage the library flags to get this to work?)
>>>
>>
>> Update: I managed to get all the generic *nix GUB dependencies building
>> on the MacStadium box.  Now I'm into the Darwin-specific ones...and of
>> course it *assumes* that it's cross-compiling them, which causes some
>> problems.  Before I spend too much time looking aimlessly: does anyone know
>> where in the GUB source code it figures out if it's cross-compiling?  I
>> think I may need to change the logic there, and I'm not sure where to find
>> it.  I'll find it eventually, of course, but if anyone can point me to the
>> right place, it would make the process go faster.
>>
>
> Further update: I've had a look through as much of the GUB source code as
> seemed relevant, and I can't for the life of me figure out where it
> determines if it's cross-compiling.  I think I need a bit of help here from
> someone who understands better how GUB works.
>

BTW, what I’ve done so far is at
https://github.com/gperciva/gub/pull/69 if anyone wants to take a look.

>
> Best,
> --
> Marnen Laibow-Koser
> [hidden email]
> http://www.marnen.org
>
--
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

> BTW, what I’ve done so far is at
> https://github.com/gperciva/gub/pull/69 if anyone wants to take a
> look.

Looks good, thanks (I left one remark).


   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
In reply to this post by marnen
On Thu, Oct 17, 2019 at 7:08 PM Marnen Laibow-Koser <[hidden email]>
wrote:

>
>
> On Thu, Oct 17, 2019 at 6:52 PM Hans Åberg <[hidden email]> wrote:
>
>>
>>
>> > On 18 Oct 2019, at 00:30, Marnen Laibow-Koser <[hidden email]>
>> wrote:
>> >
>> > On Thu, Oct 17, 2019 at 6:24 PM Hans Åberg <[hidden email]> wrote:
>> >
>> >> I made an installer into /opt/lilypond/ on MacOS 10.15, which you might
>> >> try out.
>> >
>> >
>> > With port mdmg/mpkg, or some other way?
>>
>> Yes, see
>> https://lists.gnu.org/archive/html/lilypond-devel/2019-03/msg00065.html
>>
>> > How do I try this out?
>>
>> Try this link:
>> https://web2.storegate.com/share/oCQjV4r
>>
>
> Awesome, thanks; I’ll try it when I get a chance. I still want to get an
> .app bundle built, but it’s good to know that the mdmg approach actually
> works as advertised. :)
>

Some updates.  For the time being, at least, I've changed approaches.
Since I couldn't understand much of GUB's OS detection logic, and no one
seemed able to help with that, I abandoned GUB entirely for my latest
attempt and used MacPorts to build a 64-bit LilyPond binary (thanks,
Werner!).

My current plan is now to build a 64-bit build of LilyPad.app and put the
LilyPond binary in there, then use
https://github.com/auriamg/macdylibbundler or some similar tool to package
the dylib dependencies in the app bundle.  While it's overcomplicated
thanks to poor documentation and obsolescent ways of doing things, this
seems like a potentially easy way to get a usable 64-bit LilyPond Mac .app
bundle that will run on Catalina.

Once I produce a usable Mac 64-bit build, I intend to automate the process
(probably with something like Buildkite) and be able to produce usable
builds for every future release.

Thoughts?  Suggestions?  Considerations?  Anyone want to help?

Best,
--
Marnen Laibow-Koser
[hidden email]
http://www.marnen.org
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

Hans Åberg-2

> On 7 Jan 2020, at 21:52, Marnen Laibow-Koser <[hidden email]> wrote:
>
> Some updates.  For the time being, at least, I've changed approaches.
> Since I couldn't understand much of GUB's OS detection logic, and no one
> seemed able to help with that, I abandoned GUB entirely for my latest
> attempt and used MacPorts to build a 64-bit LilyPond binary (thanks,
> Werner!).
>
> My current plan is now to build a 64-bit build of LilyPad.app and put the
> LilyPond binary in there, then use
> https://github.com/auriamg/macdylibbundler or some similar tool to package
> the dylib dependencies in the app bundle.  While it's overcomplicated
> thanks to poor documentation and obsolescent ways of doing things, this
> seems like a potentially easy way to get a usable 64-bit LilyPond Mac .app
> bundle that will run on Catalina.

FYI, it is possible to build apps using MacPorts, for example, there is emacs-app that installs Emacs.app in /Applications/MacPorts/, and it seems working if copied out of that directory.



Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

marnen
On Tue, Jan 7, 2020 at 4:16 PM Hans Åberg <[hidden email]> wrote:
[...]

>
> FYI, it is possible to build apps using MacPorts, for example, there is
> emacs-app that installs Emacs.app in /Applications/MacPorts/, and it seems
> working if copied out of that directory.


Thanks, I looked for something like that but didn’t see a general method.
Do you have any idea how this is done?

Also, of course, the point is to do this in a way that doesn’t require the
end users to have MacPorts.

Best,
--
Marnen Laibow-Koser [hidden email] http://www.marnen.org Sent from Gmail
Mobile
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

Dev mailing list
In reply to this post by marnen
Am Dienstag, den 07.01.2020, 15:52 -0500 schrieb Marnen Laibow-Koser:

> On Thu, Oct 17, 2019 at 7:08 PM Marnen Laibow-Koser <
> [hidden email]
> >
> wrote:
>
> >
> > On Thu, Oct 17, 2019 at 6:52 PM Hans Åberg <
> > [hidden email]
> > > wrote:
> >
> > >
> > > > On 18 Oct 2019, at 00:30, Marnen Laibow-Koser <
> > > > [hidden email]
> > > > >
> > >
> > > wrote:
> > > > On Thu, Oct 17, 2019 at 6:24 PM Hans Åberg <
> > > > [hidden email]
> > > > > wrote:
> > > >
> > > > > I made an installer into /opt/lilypond/ on MacOS 10.15, which you might
> > > > > try out.
> > > >
> > > >
> > > > With port mdmg/mpkg, or some other way?
> > >
> > > Yes, see
> > > https://lists.gnu.org/archive/html/lilypond-devel/2019-03/msg00065.html
> > >
> > >
> > > > How do I try this out?
> > >
> > > Try this link:
> > > https://web2.storegate.com/share/oCQjV4r
> > >
> > >
> >
> > Awesome, thanks; I’ll try it when I get a chance. I still want to get an
> > .app bundle built, but it’s good to know that the mdmg approach actually
> > works as advertised. :)
> >
>
> Some updates.  For the time being, at least, I've changed approaches.
> Since I couldn't understand much of GUB's OS detection logic, and no one
> seemed able to help with that, I abandoned GUB entirely for my latest
> attempt and used MacPorts to build a 64-bit LilyPond binary (thanks,
> Werner!).
>
> My current plan is now to build a 64-bit build of LilyPad.app and put the
> LilyPond binary in there, then use
> https://github.com/auriamg/macdylibbundler
>  or some similar tool to package
> the dylib dependencies in the app bundle.  While it's overcomplicated
> thanks to poor documentation and obsolescent ways of doing things, this
> seems like a potentially easy way to get a usable 64-bit LilyPond Mac .app
> bundle that will run on Catalina.
>
> Once I produce a usable Mac 64-bit build, I intend to automate the process
> (probably with something like Buildkite) and be able to produce usable
> builds for every future release.
>
> Thoughts?  Suggestions?  Considerations?  Anyone want to help?
By far no Mac expert, but if dynamic libraries are problematic would it
help to have a static executable? I experimented with such a setup for
Linux, and I eventually got it to build. Not sure what the status of my
script is, I can try to dig it up...

Jonas

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: macOS 64-bit

marnen
On Tue, Jan 7, 2020 at 4:35 PM Jonas Hahnfeld <[hidden email]> wrote:
[...]

> By far no Mac expert, but if dynamic libraries are problematic would it
> help to have a static executable?


Maybe.  If I understand correctly, though, .app bundles are *designed* to
easily contain dylibs, frameworks, and other dependencies, so (assuming
something like dylibbundler can help automate the packaging process) that’s
the least of our problems.

Nontechnical Mac OS X users are not accustomed to dealing with “naked”
executables not contained in .app bundles.  The GUI doesn’t even provide a
good way of doing so; it’s just not the way the OS works.

In other words, for typical users, the executable is going to have to get
packaged in an .app bundle regardless of whether it’s statically or
dynamically linked.

I experimented with such a setup for
> Linux, and I eventually got it to build. Not sure what the status of my
> script is, I can try to dig it up...


That could be useful; I’d like to see it if possible.  Thanks!


>
> Jonas


Best,

>
> --
Marnen Laibow-Koser [hidden email] http://www.marnen.org Sent from Gmail
Mobile
1234567