When building for iOS corrosion does not respect the XCode output directory

[vasilakisfil]

Hello, I am trying to build a rust library for iOS.

I have the following snippet:

corrosion_import_crate(
    MANIFEST_PATH Cargo.toml
    CRATE_TYPES staticlib
    CRATES foo
    PROFILE dev
    FEATURES apple
)
add_library(foocpp STATIC support/compat.cpp)
target_link_libraries(foocpp PUBLIC foo)

It's straightforward: a rust library with extern "C" exported functions and a simple cpp snippet that uses those bindings and builds on top of them simple C++ functions that can be used easily from C++ projects.

Then I run the following:

cmake -B cmake_build -G Xcode \
        -DCMAKE_SYSTEM_NAME=iOS \
        -DCMAKE_BUILD_TYPE=Debug \
        -DCMAKE_OSX_ARCHITECTURES=arm64 \
        -DCMAKE_OSX_DEPLOYMENT_TARGET=12.0 \
        -DIOS=true 

and finally:

cmake --build cmake_build --config Debug --target ALL_BUILD

After building finishes, the libfoocpp.a ends up correctly in cmake_build/Debug-iphoneos/libfoocpp.a while the libfoo.a ends up in cmake_build/libfoo.a (wrong). So basically corrosion somehow messes up the xcode output directory as it doesn't take into account theCONFIGURATION (Debug) and the CMAKE_OSX_SYSROOT (iphoneos).

How can we fix this ?

[jschwe]

You could set ARCHIVE_OUTPUT_DIRECTORY to the directory you want (${CMAKE_CURRENT_BINARY_DIR}/$<CONFIG>-${CMAKE_OSX_SYSROOT}). I didn't test, but it should work as a short-term fix you can do on your end.

[vasilakisfil]

@jschwe this works half-way as in Xcode/iOS it's common to use the same build configuration for both iphone and simulator through xcodebuild. So setting ARCHIVE_OUTPUT_DIRECTORY will only work if you build one, but not for both.

[jschwe]

It's currently not possible anyway to build for both with one CMake configuration in corrosion.

corrosion/cmake/Corrosion.cmake

Lines 1265 to 1268 in 5239c1b

	# This works fine, except when compiling for ios. See https://cmake.org/pipermail/cmake/2016-March/063050.html
	# XCODE_EMIT_EFFECTIVE_PLATFORM_NAME=OFF is supposed to prevent emitting EFFECTIVE_PLATFORM_NAME, but even
	# with CMake 4.1 and the variable set to off EFFECTIVE_PLATFORM_NAME still leaks into generator expressions,
	# and is not correctly replaced at build time

To work around the issue of EFFECTIVE_PLATFORM_NAME leaking into generator expressions, and not being resolved at build time, we hardcode the platform at configure time.

corrosion/cmake/Corrosion.cmake

Lines 1283 to 1284 in 5239c1b

	# This is a hack to fix $EFFECTIVE_PLATFORM_NAME not expanding in TARGET_LINKER_FILE_DIR
	set(linker_dir "$<PATH:REPLACE_FILENAME,${linker_dir},$<CONFIG>${platform_name}>")

As far as I see, this would need a fix upstream in CMake, since I don't see anything we can do in corrosion about it (unless there is a generator expression which contains the -sdk flag, but I didn't see one).

[akitchen]

It's currently not possible anyway to build for both with one CMake configuration in corrosion.

This is true, and unfortunately it's not something corrosion or CMake can fully solve for due to the dynamic nature of multi-platform/multi-SDK projects in Xcode. An integration can be complicated because iphoneos and iphonesimulator are two different SDKs, and the developer may expect to switch back and forth between them and other platforms/SDKs in Xcode.

Xcode sets a number of environment variables at build time which need to be interpreted correctly in order to drive the rust toolchain. Furthermore, libraries built from a script phase are not considered "native targets" by the Xcode build system which brings some additional complexity.

I have attempted to solve these problems on my own fork of corrosion for a complex multi-library project targeting iOS, iphonesimulator and macos, and it's working pretty well for our purposes. We're doing something similar to what's described here, integrating one or more rust libraries with extern "C" exported functions and companion libraries of bindings into a larger system with many other C++ static libraries.

@jschwe of course this code has diverged from the main trunk but would you be open to considering a solution like this? master...akitchen:corrosion:xcode-dynamic-script-target . This solution introduces a new script phase in Xcode which handles Xcode's build-time variables and translates them into an appropriate cargo rustc command invocation. I would still need to update it with the latest changes on main and provide documentation on integrating the rust library into an Xcode project. Once it is integrated into a parent Xcode project it works very well, and the developer can switch between any of the supported platforms and configurations in Xcode without needing to regenerate from CMake.

[jschwe]

@akitchen Sorry for the slow reply here. That looks pretty interesting and looks like a practical solution. Historically, corrosion has tried to be CMake only (for cross-platform consistency), but since this anyway only would affect MacOS hosts using a bash script would be fine with me.

This solution introduces a new script phase in Xcode which handles Xcode's build-time variables and translates them into an appropriate cargo rustc command invocation. I would still need to update it with the latest changes on main and provide documentation on integrating the rust library into an Xcode project

I'm not really familiar with using Xcode, but at least from corrosions side it should also work in regular CMake builds with the XCode Generator, right?

[akitchen]

Yes, that's the idea.

I'll update my fork with the main branch soon and open a PR for discussion.

[akitchen]

Apologies for partially hijacking this thread, but a draft PR is opened here: #658 . I think this solution may partly help with the problem stated in the original post, although it may need to be customized further to control where the rust static library is produced.