On 10 Oct 2022, at 20:29, Jonas Hahnfeld <hah...@hahnjo.de> wrote: > Yes, I build on macOS 10.15 and it will work on versions newer than > that, as also announced with the first release of this infrastructure: > https://lists.gnu.org/archive/html/lilypond-user/2022-02/msg00155.html
I wanted to say that I didn’t mean to cause any friction in raising this issue about min deployment targets. I did my first serious project in lilypond in 2021 and was super impressed with what I was able to achieve in terms of custom notation / layout etc. It’s an excellent project, and when recently moving to a newer MacOS the lack of as easy a route to running it was a little frustrating - I’m just interested in it being as available as possible to different people. I’m personally very grateful to anyone working on it for maintaining something so valuable. >> I read that SDK 10.14.1 supports 10.9 as the oldest version > > So you checked all of LilyPond's dependencies and can guarantee that it > will stay like this forever? I am on Big Sur (11.6) and I can still choose 10.9 as a deployment target. FWIW I consider that to be a little beyond what I’d normally support (10.11 is about my cutoff), but it is still possible. In terms of the dependencies, that was the thing that I hadn’t considered detail and it really depends how the build system works how much hassle it would be - if this can be set in one place then it would be straightforward to try, if it’s a matter of the individual dependencies approach to building then it’s totally different. As far as I can reason any incompatibility should break at compile time, however, rather than runtime, as this is about hooks in OS routines, and not any of the other code. It looks (from above) like a MacPorts build for 10.13 does currently work. > For the record, the easier variant of this setting is the environment > variable MACOSX_DEPLOYMENT_TARGET. That makes sense - that’s what you’d set in Xcode - I just went directly for the clang/llvm docs and I wasn’t sure if it was an alias, but an environment variable would be easiest. >> Whatever Jonas is able to manage with his build setup, > > I'm not going to work on anything. I have been alone trying to get a > build for macOS even though I don't even use Apple hardware and other > core developers do. It will take somebody willing to work on this > effort *and commit to maintaining it* because I don't think it's a good > idea to release something half-working. 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? I would be interested in helping out if it is needed, and I maintain and work on some other open source projects (https://github.com/AlexHarker <https://github.com/AlexHarker> / https://github.com/iPlug2/iPlug2 <https://github.com/iPlug2/iPlug2>), with Mac as my main platform for development. Jonas - thanks for your work on the Mac builds. It is appreciated here and I’m sure by lots of other people. Alex
