[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mon, 2 Aug 2021 11:49:35 +0200
An Mac .app bundle is self-contained, with everything it needs inside it.
That’s why you can place anywhere in your files hierarchy and there can’t be
conflicts with other applications, including other versions of the same .app.
In particular, the LilyPond .app bundle contains the python version to be used
jacquesmenu@macmini: ~ > ls -sal
0 drwxr-xr-x@ 4 jacquesmenu admin 128 Feb 12 2017 .
0 drwxr-xr-x@ 18 jacquesmenu admin 576 Jun 27 2017 ..
184 -rwxr-xr-x@ 1 jacquesmenu admin 92080 Feb 12 2017 LilyPond
64 -rwxr-xr-x@ 1 jacquesmenu admin 29564 Feb 12 2017 python
I didn’t know, though, that moving it other that with the Finder (in the
terminal with mv, for example) would raise issues in the recent, 64 bit only OS
The LilyPond executable inside it can be launched thru its access path and used
in Frescobaldi… provided it can run on the given architecture:
jacquesmenu@macmini: ~ >
-bash: /Applications/LilyPondWithLilyjazzFont.app/Contents/MacOS/LilyPond: Bad
CPU type in executable
I currently use this version, which is not part of any .app bundle:
jacquesmenu@macmini: ~ > type lilypond
lilypond is /opt/local/bin/lilypond
jacquesmenu@macmini: ~ > lilypond --version
GNU LilyPond 2.22.1
Copyright (c) 1996--2021 by
Han-Wen Nienhuys <email@example.com>
Jan Nieuwenhuizen <firstname.lastname@example.org>
This program is free software. It is covered by the GNU General Public
License and you are welcome to change it and/or distribute copies of it
under certain conditions. Invoke as `lilypond --warranty' for more
> Le 2 août 2021 à 08:35, Jonas Hahnfeld via LilyPond user discussion
> <email@example.com> a écrit :
> Am Sonntag, dem 01.08.2021 um 20:53 +0000 schrieb Carl Sorensen:
>> On 8/1/21, 10:21 AM, "lilypond-devel on behalf of Jonas Hahnfeld via
>> Discussions on LilyPond development"
>> <firstname.lastname@example.org on behalf
>> of email@example.com> wrote:
>>> For me, personally, I'd prefer to see us follow up with either Marnen's or
>>> Jaques's work (they may actually be very similar -- I'm not sure) so we can
>>> get installable .app bundles, not just installed binaries. Installable app
>>> bundles make it very easy to use different versions of LilyPond in
>> Can you explain? Just extracting different versions of the binaries
>> produced by the above system will work just fine. IIRC you only need to
>> adjust the paths in Frescobaldi, right?
>> I suppose that I can have different name binaries in my bin folder, with a
>> different name for each version. As far as I know the binaries are
>> generally installed to some folder other than Applications (I don't remember
>> where it ended up when I tested it.
> Ok, would be interesting to know...
>> With the app bundle, I can rename the app bundle, and all of the necessary
>> bin files are in each .app bundle. I don't have to worry about what is the
>> appropriate system path. It's possible that it's no more difficult with
>> your binaries, rather than the .app bundles. It's just not my standard
>> process. GUB produces .app bundles, so that's what I'm used to using.
> You should be able to unpack the binaries to different directories, and
> use them in parallel as you wish.
>> The other thing that I thought tha .app bundles provided is built-in proper
>> versions of all the necessary utilities, so I don't need to worry about
>> clashes with improper versions of utilities. I haven't actually run into
>> any problems with clashes, but I also haven't tried multiple lilypond
>> binaries with different names on my system -- I've just used different app
> I would claim it's even less error-prone with the way I'm proposing
> because everything is statically linked, so you can never run into the
> problem that one version of LilyPond finds a library from another
>> I'm an old dog, but not so old that I can't learn new tricks. Maybe I just
>> need to learn new tricks and your method is perfectly sufficient. If so,
>> please let me know.
> Feel free to try the current proof-of-concept, the overall idea of the
> approach has worked on all systems that I tested so far.