Release build for mac will enable bitcode

[shiena]

In Release/Distribution builds for macOS/iOS/visionOS, INTERPROCEDURAL_OPTIMIZATION is ON so bitcode is enabled. I would like to see bitcode disabled by default as it has been deprecated since Xcode14. Also, there are cases where bitcode is required for older models, so I think it would be better to be able to enable it as an option.

Probably related to the following issue and pull req. https://github.com/jrouwe/JoltPhysics/issues/418 https://github.com/jrouwe/JoltPhysics/pull/357

[mihe]

What errors/warnings are you seeing exactly?

Distributing (and thus building for) bitcode is indeed deprecated, and while LTO/IPO in LLVM does similarly emit LLVM bitcode into the object files in order to optimize across them, I see no mention of LTO in AppleClang being deprecated along with it, and frankly I have a hard time seeing that being the case.

[shiena]

INTERPROCEDURAL_OPTIMIZATION causes the -flto=thin option to the compiler and generates an object file with bitcode output. This causes an Unknown header: 0xb17c0de error when creating the xcframework from the .a file. If INTERPROCEDURAL_OPTIMIZATION is turned off, bitcode is not output.

[mihe]

I assume then that you're not generating/building your Xcode project with CMake (and referencing the Jolt CMake target as part of that) but instead manually bundling the statically linked XCFramework?

If that's the case, I suppose there is some argument for disabling LTO by default when targeting Apple platforms, since there's the possibility of the static libraries being bundled into an XCFramework bundle. It could also be conditionally disabled only when PROJECT_IS_TOP_LEVEL is true and BUILD_SHARED_LIBS is false, in order to cater to FetchContent and shared libraries, but I'm not sure it's worth the hassle.

Frankly I'm not seeing much of a difference at all in PerformanceTest on my M2 Mac Mini with or without LTO, for reasons I can't quite understand, so that would seem to make this decision a lot simpler. I don't have an x86 Mac to test with anymore though, but those are quickly becoming irrelevant anyway I guess.

[jrouwe]

I'm not really sure what to do with this. The way I read the release notes from Apple is that they remove bitcode from apps uploaded to the store. The reasoning seems to be that the binary format of bitcode changes too often, meaning it cannot be reliable used to recompile the same code for different architectures. Besides they got rid of all other architectures anyway, so they don't need it anymore.

The LTO flags haven't been removed, and can still be useful when you want to get more optimized code in case you link the static library into your code. In the case of an xcframework, they're probably not desired as they potentially break with every new clang release.

Since it is really easy to turn LTO off for an xcframework (set the project setting ``INTERPROCEDURAL_OPTIMIZATION` to off) and FetchContent compiles and links the static library every build, the breaking format changes are not an issue. So I'm tempted to leave things as they are (possibly adding some extra information to the build docs on what to do if you receive the error).