search

libgdx / gdx-jnigen

jnigen is a small library that can be used with or without libGDX which allows C/C++ code to be written inline with Java source code.
Apache License 2.0
59 stars 26 forks source link

[iOS] Add support for arm64 simulators and replace use of fat static lib with xcframework #28

Closed Berstanio closed 2 years ago

Berstanio commented 2 years ago

Hey, this pr should add support for arm64 simulators. It relies on a patch in mobivm which is currently not in a release version (https://github.com/MobiVM/robovm/commit/a751e3fd344dafdb2c296fb12e7bb6a4a49c304e) An example of how the static xcframeworks can be integrated with the robovm.xml can be found in the "JnigenIOSJarTask.java" class. This would be probably a very breaking change since everyone that relies on jnigen for ios would need to change their robovm.xml file. (except they rely on the generated robovm.xml file)

Any comments or ideas about what could be done better are welcome! I would understand if these changes are to breaking, but I wouldn't really know a less breaking solution.

PokeMMO commented 2 years ago

This would be probably a very breaking change since everyone that relies on jnigen for ios would need to change their robovm.xml file. (except they rely on the generated robovm.xml file)

Is this just for users compiling projects via jnigen, or for users consuming them? Is there any change required for the average libgdx user who just used gdx-setup to depend on libgdx and some plugins such as gdx-freetype?

Could this solution vary between depended on projects? If libgdx switches to this, can the user continue to depend on another library which uses the legacy method?

Berstanio commented 2 years ago

Is this just for users compiling projects via jnigen, or for users consuming them? Is there any change required for the average libgdx user who just used gdx-setup to depend on libgdx and some plugins such as gdx-freetype?

No, the change is only relevant for compiling. After that the right robovm.xml is packed inside the jar. The only change the average libgdx user would need to do is updating to the newest MobiVM version 2.3.15.

Could this solution vary between depended on projects? If libgdx switches to this, can the user continue to depend on another library which uses the legacy method?

Yes, that should be possible! It's only a change in compiling and generating the packed robovm.xml.

Berstanio commented 2 years ago

I created a libGDX branch that shows what changes would need to be implemented on libGDX side to support this. https://github.com/Berstanio/libgdx/tree/m1-simulator But as it looks like Apple has broken OpenGL ES for the arm64 simulators for iOS 14+, so in this form it can't be really tested. For testing I made another branch based on my metalange branch. https://github.com/Berstanio/libgdx/tree/metalangle-m1

Berstanio commented 2 years ago

Updated it and it now works with the new robovm xml generation!

PokeMMO commented 2 years ago

Merged!

Berstanio commented 2 years ago

Great! Should I open the related pr in libgdx for adjusting to the new changes? Or should this be done when the jnigen version is increased? @PokeMMO

PokeMMO commented 2 years ago

I'd suggest to open the PR as a draft, using the snapshot to test.