Re: another 'wrong type argument' error

[Alex Harker]

Thanks for clarifying what would be helpful. I’m currently trying to get lilypond building locally with these scripts, although I’ve not managed to fully complete that process yet.

The dependencies were pretty much fine, but I had a 404 with zlib whilst downloading the source and had to move to the next version to get rid of that.

I also managed to build the dependencies with a lower Mac OS requirement than the machine I was building on with very little in the way of added python code.

When building lilypond I hit an issue with some old/partial version of harfbuzz in usr/local/ which I removed.

Then I hit an error compiling the lexer, which as of yet I’ve not been able to trace.

I realise that the first priority is probably testing, but I’d like to be able to build as I feel I might be able to be more useful in that case. I also understand the fear about things breaking out of the blue, but for MacOS dev my experience is that if support for old Ones became an issue that’s more likely to be a compile-time, rather than a runtime issue.

In terms of testing - are there tests that would be good to run, or is the required testing more general (e.g. - it runs on an arbitrary lilypond score file).

In terms of Lilypond.app - I suspect this would be useful to maintain - it’s how I was using it until my latest system (at which point I moved to Frescobaldi to have a GUI - that’s a much nicer environment). I think the majority of Mac users wouldn’t be comfortable with a command-line interface, or having to deal with a separate GUI/environment to be installed onto. Thus, from my view this is about new adopters - getting people to try Lilypond in the first place.

I saw a branch that looked like it might be the old Mac app - I’d be happy to take a look once I can get lilypond building. Can someone confirm where this is? I presume the first goal would simply be to resurrect it as is? The packaging part is trivial - it’s the app itself will require more of look, but there are also tighter requirements in terms of code signing etc. these days in terms of getting around Apple’s gatekeeper and that would be something to think about later down the line, but only once the app was back up an running locally.

Let me know also if I should continue any more technical questions here, or on another list.

Alex

On 14 Oct 2022, at 19:02, Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:

On Fri, 2022-10-14 at 04:30 +0000, Werner LEMBERG wrote:

In the spirit of my first comments in this email I’ll directly ask
if the project needs help testing or working on the Mac build
system at all?

Yes, we need help – namely for taking *permanent* care of the MacOS
releases in

  https://gitlab.com/lilypond/lilypond/-/releases

that have been built with the scripts in

  https://gitlab.com/lilypond/lilypond/-/tree/master/release

With 'permanent' I mean that the automatically created and released
binaries should be regularly tested on actual Mac hardware to check
whether they work as expected.  Jonas's fear is too real that some
day deployment support for older OS versions will break out of the
blue, unfortunately.

Slight clarification: the binaries are not created "automatically" by
some CI pipeline or the like, but by executing the scripts linked above
on a macOS node provided by MacStadium. But yes, testing them on a
regular basis and in a wider set of configurations would be great.

As Jonas writes: He isn't a MacOS users, and none of us main
developers is either.  It was a heroic effort of him to set up the
scripts, but details like handling deployment targets to make this
work on older MacOS versions needs a dedicated specialist.

The other point that was raised in the past was packaging as a
LilyPond.app and a .dmg that users are more familiar with. In the end,
it's "just" a special directory with some metadata files, but it needs
somebody with the appropriate knowledge and hardware to figure out what
needs to be done (if the idea is useful).

Jonas