This pr intends to replace the static ios libraries with dynamic ones.
Dynamic libraries are supported since iOS 8+ and the min iOS version for jnigen is 9. Every other backend already produces dynamic libs.
Static libs have multiple downsides, the one that lead to this pr are clashing symbols. If jnigen-lib A and jnigen-lib B contain both a similiar symbol C, it is very hard to fix this.
Also I had occasionally struggles with dead code stripping, which wouldn't have happen with dynamic libs.
The change should be in general non-breaking. The only edge cases I can think of are:
When having a custom robovm.xml, that would need minimal custom adjustment.
If jnigen-lib A needs non system library B, which only for ios gets linked during final build. But I guess this is very unlikly.
The base plist is copied from MetalANGLE. This is not ideal, but I don't know a better way. Otherwise we would need to generate a xcodeproj on the fly, which is probably a bit overkill.
It also needs to be decided, what to put as the bundle identifier of the framework.
This pr intends to replace the static ios libraries with dynamic ones. Dynamic libraries are supported since iOS 8+ and the min iOS version for jnigen is 9. Every other backend already produces dynamic libs. Static libs have multiple downsides, the one that lead to this pr are clashing symbols. If jnigen-lib A and jnigen-lib B contain both a similiar symbol C, it is very hard to fix this. Also I had occasionally struggles with dead code stripping, which wouldn't have happen with dynamic libs.
The change should be in general non-breaking. The only edge cases I can think of are:
The base plist is copied from MetalANGLE. This is not ideal, but I don't know a better way. Otherwise we would need to generate a xcodeproj on the fly, which is probably a bit overkill. It also needs to be decided, what to put as the bundle identifier of the framework.
Fixes #35