Fix macOS packaging

[pkoryzna]

This produces a .dmg disk image file with VisiCut and JRE bundled using jpackage that runs on modern macOS versions. The resulting .app bundle is not signed of course, so still have to go to Settings to allow on first startup. that would require setting up entitlements and paying Apple 99 USD/year :(

this fixes #762 by removing the universalJavaStub :)

[mgmax]

Thanks a lot for your contribution! Good to see that it makes the build process easier than before. I can't test it because I have no Mac, so my following questions are just from looking at the source code.

What's the purpose of "inputs.version", is this specific to Mac? For other platforms the version is auto-detected in the build process based on Git history.

What will happen if someone tries to run the macos-jpackage build on non-Mac machines? Would it be helpful to add a check and error message here?

[pkoryzna]

Thanks for the feedback!

What's the purpose of "inputs.version", is this specific to Mac? For other platforms the version is auto-detected in the build process based on Git history.

Ah, I see that this is left over from my manual testing. This just makes running the pipeline easier from a non-tagged commit like HEAD of a branch, since the script cannot tell the version from git in that situation. I can remove this

What will happen if someone tries to run the macos-jpackage build on non-Mac machines? Would it be helpful to add a check and error message here?

You're right, just tried it in docker and jpackage fails since it can only build them on macOS. Error: Option [--mac-package-identifier] is not valid on this platform. I will add a check.

[pkoryzna]

@mgmax I added the macOS check to the distribute.sh and removed the leftover bits from the build pipeline.

[renebohne]

Hi @pkoryzna, I’ve tested the macOS build process using ./distribute/distribute.sh macos-bundle on my M1 Mac. It’s a great improvement, but I ran into two small issues that currently block the build on macOS 26.2:

sed compatibility in generatesplash.sh:

On macOS (BSD sed), the splash generation fails with the error bad flag in substitute command: '#'. This is caused by the trailing # in the command:
cat splashsource.svg | sed s#insert#$VERSION#g# > splash.svg
BSD sed interprets that last # as an invalid flag. Switching to standard slashes and using quotes (important for the variable) makes it compatible with both BSD and GNU:
sed "s/insert/$VERSION/g" splashsource.svg > splash.svg

jpackage version format strictness:

jpackage on macOS is very strict regarding the --app-version flag. It rejected the auto-generated git version (e.g., 2.1-36-gfd7d2fc2) because of the non-numeric characters and the git hash. I had to manually override the version to a numeric format (e.g., 2.1.36) to get it to work. It would be helpful if distribute.sh could sanitize the version string for macOS targets.

Once I applied these two fixes locally, the build ran perfectly. The resulting .app bundle looks solid, and the .plf file associations are working exactly as expected.

Thanks for modernizing the macOS build process!

[pkoryzna]

@renebohne thank you for the feedback, I will get back to this soon hopefully!

[pkoryzna]

@mgmax @renebohne i think i fixed the version issues, could you take a look again? thanks!

[mgmax]

looks good, except that something is wrong in the MacOS version string calculation:

sanitize_mac_version 2.1-39-g05863063
+++ echo 2.1-39-g05863063
+++ sed 's/^\([0-9]*\.[0-9]*\.[0-9]*\).*$/\1/g'
++ SANITIZED=2.1-39-g05863063
++ echo 2.1-39-g05863063
+ MACOS_APP_VER=2.1-39-g05863063

which should result in 2.1.39.

[pkoryzna]

hi, sorry that I am getting back so late to this, I was quite busy. i just pushed a fix that should handle versions like 2.1-39-g05863063 and also just 2.1