Break output by platform (iOS, macOS etc)

[jfro]

This was mentioned in #14 but probably can be it's own ticket. I've run into issues due to my rust library being used by both macOS & iOS but sharing the same output path. Or when trying to build iOS & iOS Simulator libraries. I ended up in an example I shared with someone doing cargo clean before cargo lipo --xcode-integrity to ensure it doesn't accidentally link the wrong platform library.

This same change could also do a bonus and check that you're not trying to build iOS & macOS into the same library. Apple seems to say this is not supported. They point at their XCFramework if you want 1 thing across platforms.

The output path could be something like what rust already does except just trim everything but the platform:
target/universal-macos/debug/<lib>
target/universal-iossimulator/debug/<lib>
target/universal-ios/debug/<lib>
Etc.

I possibly can try to PR something up even if I find some time.

[TimNN]

Hi @jfro!

Thanks for the bug report and your offer to contribute! I would accept such a PR (as long as it was guarded by a new flag).

Though if you just depend on the lipo-generated library from Xcode, then there is another option (which I should probably properly document in the readme, because IMO that's a better solution than using lipo, though an updated cargo-(lipo)-xcode-integ command would probably still be helpful):

You can use architecture specific environment variables in Xcode (see my comment on reddit from some time ago).

Note that you have to edit your project.pbxproj manually, but then you can do stuff like (and point them directly at the appropriate /target/... directories):

				"LIBRARY_SEARCH_PATHS[sdk=iphoneos*]" = /test/foo;
				"LIBRARY_SEARCH_PATHS[sdk=macosx11.1][arch=arm64]" = /test/bar;
				"LIBRARY_SEARCH_PATHS[sdk=macosx11.1][arch=x86_64]" = /test/buz;

which shows up in XCode as:

[jfro]

actually it looks like Xcode has GUI for adding those variants to build settings now!

Also maybe it's super unlikely, but my worry was cargo-lipo producing a universal binary to the same path regardless of platform/archs used, so you can accidentally get the wrong arch if your build setup doesn't realize it needed to run cargo-lipo again. Maybe this is just me being overly cautious and most setups wouldn't run into this.

I do still think there may be benefit in maybe some easy platform arguments, but still trying to nail down some oddities with Xcode & this. For example if you build a rust library against aarch64-apple-ios technically that's for iOS devices, but if you link it with OTHER_LINKER_FLAGS into say a wrapping framework, it'll work in M1 iOS Simulator as well. But not in the "framework/library" UI. Maybe for good reason, and maybe there isn't a target for that specific setup yet, still looking into it. It at least works with simple test cases & other linker flags....

[logankeenan]

I'm a bit confused. If I update my LIBRARY_SEARCH_PATHS to point to the corresponding target and architecture then what do I point to under Frameworks, Libraries, and Embedded Content if I no longer have a universal *.a file without lipo?

[jzxchiang1]

^ I have the same question. My linker is complaining.