build(binding): MacOS ARM64 native binaries

[rexfleischer]

Description

Change to add the native binaries for Mac OS ARM64. This is based on #112 and #190. I am not able to test all the different binaries, but I was able to test the non-freetype macos-arm64.

Type of change

• [X] Minor changes or tweaks (quality of life stuff)
• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [X] This change requires a documentation update

[Displee]

Yes please! I need this so bad!

[rexfleischer]

I haven't checked the all one because I didn't know there was one! I will do that as well. Thanks for the reviews.

[rexfleischer]

Update will be in soon.

Ok, this was a couple months ago so I'm not sure if I'm remembering correctly. Here are some notes (and maybe a follow up question):

• I originally assumed that I didn't need to include the built natives in bin. I forgot why I thought that... However, I'm copying them into bin now. Is there a standard way of doing this that I'm missing? I just got the ./gradlew imgui-binding:generateLibs -Denvs=macosarm64 -Dfreetype=true/false working and copied /tmp/imgui/libsNative/macosxarm64/libimgui-javaarm64.dylib to bin.
• I couldn't get the freetype build working until I executed the FreeType - Install (MacOS-arm64) from .github/workflows/ci.yaml step. This sound reasonable?
• After executing ./gradlew :imgui-app:shadowJar, I executed jar tf imgui-app/build/libs/imgui-app-686c27-all.jar and now see the libimgui-javaarm64.dylib library.

I do have one follow up question. I see in the image-app build script for the jar, it copies in the non-freetype linux and mac natives, but only the freetype windows native. What is the reason for this?

[rexfleischer]

I opened this because both #112 and #190 seemed to be abandoned and had either changes requested by the maintainer or had other issues. If you can get 190 in, I don't care either way. However, 190 still has changes requested by the maintainer in 112.

your PR still cannot be compiled

how do you figure this? It compiles: https://github.com/rexfleischer/imgui-java/actions/runs/9118399802

seems far away from being merged

If you "neither the maintainer of this project nor an expert in imgui", how do you figure this? I'm sorry if this PR caused some turmoil, but both the other PRs seemed far away from being merged.

[rexfleischer]

Either way, @SpaiR if there is anything that can help move this PR or #190 forward, please let us know.

[SpaiR]

First of all, I apologize for the inconvenience to everyone who was waiting for the macOS ARM support and specifically for this PR to be merged. 🙏

There were several PRs, but for various reasons, I wasn't able to review them until now. However, the time has finally come!

I will merge this PR since it includes some minor CI cleanups. I also want to thank everyone who has contributed (#112 and #190). I will mention all authors in the upcoming changelog, which I believe will be released very soon (within 1-2 weeks or even sooner).

[SpaiR]

Ok, I revamped the whole concept. In PR #239, a universal binary for the ARM64 architecture was introduced. So, one dylib for all - which is great, I believe. Additionally, while working on the build scripts, I decided to resolve the longstanding issue with FreeType. As a result, FreeType is now statically compiled and enabled by default, which basically improves font quality for free. More details can be found in the PR description.