Fix: make only a single call to 'xcodebuild -create-xcframework'

[Westacular]

xcodebuild -create-xcframework writes manifest data to the root of the XCFramework in Info.plist. Although calling it repeatedly (instead of making a single call) does add the new subfolders to the bundle without wiping the previous ones, it doesn't merge the old + new manifest data together; instead, each subsequent call clobbers any existing Info.plist. As a result, the only way to use it is to make a single call, and include all of the library+header pairs at once.

Meanwhile: Is there a plan to switch swift-sodium to use an embedded XCFramework instead of a plain .a library? This would enable its use in Catalyst-based projects. There appears to be a limitation in the current version of Cocoapods that prevents it from working with a .a-based XCFramework, but that is supposed to be fixed in 1.10 (and current development versions).

[svdo]

Does coincidence exist? I also ran into this exact same issue yesterday, and I just created a fix that I was about to create a PR for :)

So instead, let me propose a slightly different solution in the same spirit as yours, namely one that iterates over the platforms. This, I feel, gives a bit cleaner code in the sense that it has less duplication:

XCFRAMEWORK_ARGS=""
for f in ios ios-simulators watchos watchos-simulators catalyst; do
  XCFRAMEWORK_ARGS="${XCFRAMEWORK_ARGS} -library ${PREFIX}/${f}/lib/libsodium.a"
  XCFRAMEWORK_ARGS="${XCFRAMEWORK_ARGS} -headers ${PREFIX}/${f}/include"
done
xcodebuild -create-xcframework \
  ${XCFRAMEWORK_ARGS} \
  -output "${PREFIX}/Clibsodium.xcframework" >/dev/null

I'm not committing anything; I'll leave it up to you whether you want to update your PR or not.

In any case I can confirm that both our approaches yield the desired result, so I hope that the PR gets merged (and released!) quickly.