Can we include lipo installation in yarn cleaninstall or as a Build Phase step for the Comm target?

We already make the assumption that the developer has rust installed, so automating the installation if necessary would let us avoid adding another step to dev environment setup?

In D4953#143621, @atul wrote:

Can we include lipo installation in yarn cleaninstall or as a Build Phase step for the Comm target?

We already make the assumption that the developer has rust installed, so automating the installation if necessary would let us avoid adding another step to dev environment setup?

This is a good idea. Added to the Build Phase

dug a little more on the LIBRARY_SEARCH_PATHS thing. basically, all those cocoa pods lines already existed in that section, but I think Xcode has a special way to handle pods so it didn't need to enumerate them in the pbxproj file. When I updated the search paths section, it explicitly wrote out everything in that section.

Can we add native/cpp/CommonCpp/grpc/grpc_client/target/ to .gitignore?

In D4953#143642, @atul wrote:

Can we add native/cpp/CommonCpp/grpc/grpc_client/target/ to .gitignore?

Sure https://linear.app/comm/issue/ENG-1706/add-grpc-client-target-directory-to-gitignore

Running into the following:

Sure https://linear.app/comm/issue/ENG-1706/add-grpc-client-target-directory-to-gitignore

I think it would be good to include in this diff to keep developer's git working directory clean

Sent these messages to Rust squad on Comm; also sharing here:

• hey team, so it looks like Varun wasn't able to land the Rust gRPC client before his vacation, based on https://phab.comm.dev/D4953 still requiring revision
• it's my understanding that this work is currently blocking a lot of people
• I won't be around next week, but I think it's important to try to unblock. did Varun talk to anybody about taking over the work while he was gone?
• if not, maybe Atul or Tomek could take a look. we just need XCode to work

One thing we need to do is add aarch64-apple-ios target

rustup target add aarch64-apple-ios

edit:

also

rustup target add x86_64-apple-ios

Then ran into an issue with the protoc command in the identity build.rs, changing it to:

tonic_build::compile_protos("../../native/cpp/CommonCpp/grpc/protos/identity.proto")?;

resolved that issue. (I know there's some ongoing work with moving the protos around, so not sure what the right approach is here, just trying to get it to build via Xcode... sure this breaks things elsewhere)

Okay yeah after those two changes (adding the targets and changing the identity.proto path get the grpc_client library to build) the iOS app builds.

As for how to incorporate them in the repo, I'm not sure.

We could add the iOS target commands to the dev environment setup + nix.

As for the path issue, I don't have full context but I know things are being moved around so once that's done changing the paths so both identity and grpc_client build correctly.

But incorporating these changes locally should unblock anyone who needs to work with grpc_client on iOS for the time being

tonic_build::compile_protos("../../native/cpp/CommonCpp/grpc/protos/identity.proto")?;

We should probably find where the build script is located, then resolve paths from there. CARGO_MANIFEST_DIR should be set to the location of the Cargo.toml https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts

nice this is finally passing CI

(Also let's add native/cpp/CommonCpp/grpc/grpc_client/target/ to .gitignore)

edit: also native/cpp/CommonCpp/grpc/grpc_client/lib.rs.cc if we aren't going to check it into the repo

In D4953#147995, @atul wrote:

(Also let's add native/cpp/CommonCpp/grpc/grpc_client/target/ to .gitignore)

edit: also native/cpp/CommonCpp/grpc/grpc_client/lib.rs.cc if we aren't going to check it into the repo

already did this

https://medium.com/swiftblade/what-the-hell-is-this-output-files-in-xcode-build-phases-bfbec6391184

(Disregard, spoke with @varun offline and I was mistaken. Will re-test and probably accept this diff momentarily.)

protoc should be found if it's on the PATH. Otherwise some library messed up because the POSIX way to find something is through PATH.

Yeah the issue is that Xcode doesn't source the user's shell profile so it only looks at what's in /etc/paths:

atul@atuls-MacBook-Pro comm % more /etc/paths 
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin

I had my non-nix protoc installed in my $HOME folder from some CMake thing I was working on a while ago. Re-followed the installations instructions in the dev environment docs and now we're good to go:

atul@atuls-MacBook-Pro comm % where protoc
/usr/local/bin/protoc

In D4953#148650, @tomek wrote:

I'm a little confused about the plan here. This diff references some files in xcode project that don't exist in the repo. When these files should be generated? When we checkout the code, is it in the correct state - no compilation errors?

The fact that we reference files that aren't in the repo and are ignored by git is confusing.

These files are generated as part of the Xcode build. Please see the shellScript part of the diff. I can add a cleanup step at the end of the build that deletes the generated files, so that we don't have to git ignore them

In D4953#148836, @marcin wrote:

I modified my local branch with with Rust and C++ code for blob native client to mirror the setup presented above. When I attempt building Build Rust Library script was producing the following errors upon cargo build command:
{F164592}
Those errors are generated when cargo tries to compile cxx crate (the one we use for C++ bindings generation). This crate contains some C++ files and it looks like the are being compiled as if they were C++98 standard.
I diagnosed that cxx crate depends on cc crate. According to docs (https://crates.io/crates/cc) its behaviour can be modified by environmental variables. So I was able to successfully compile and run (exchange data with blob service) the whole project when I modified Build Rust Library script by adding export CXXFLAGS="-std=c++14" before cargo build and adding unset CXXFLAGS after cargo lipo.
I run git grep CXXFLAGS to see whether we set this flag somewhere in CI or else to understand why I needed to introduce such modification locally but everything works fine for CI. All I found was this file: services/tunnelbroker/docker/install_cryptopp.sh:make CXXFLAGS="-DNDEBUG -g2 -O3 -std=c++11". Not 100% sure but probably it is not relevant. @varun do you have an idea why settings this flag was necessary for me to compile project?

EDIT: I found the solution. When I run clang --version I get that I am using apple clang 13.1.6 which according to this: https://stackoverflow.com/questions/71670730/default-c-standard-is-c98-in-apple-clang-13 uses c++98 as default standard if not specified. So I can make a conclusion that it is my local issue which however can be experienced by someone else as well, who is using the same compiler. @varun can we safely add those lines? My local script looks like this:

# #!/bin/bash
set -x
# The $PATH used by Xcode likely won't contain Cargo, fix that.
# In addition, the $PATH used by XCode has lots of Apple-specific
# developer tools that your Cargo isn't expecting to use, fix that.
# Note: This assumes a default `rustup` setup and default path.
build_path="$HOME/.cargo/bin:/usr/local/bin:/usr/bin:/bin"
# cd to Cargo project
cd ${SRCROOT}/../cpp/CommonCpp/grpc/blob_client/rust
# Add iOS targets for cross-compilation
env PATH="${build_path}" rustup target add aarch64-apple-ios
env PATH="${build_path}" rustup target add x86_64-apple-ios
# Install cargo lipo
env PATH="${build_path}" cargo install cargo-lipo
# Build cxx bridge. Set C++ standard for C++ rust dependencies
export CXXFLAGS="-std=c++14"
env PATH="${build_path}" cargo build
# Build universal static library (works on simulator and iOS)
env PATH="${build_path}" cargo lipo --release "${build_args[@]}"
# unset the flag
unset CXXFLAGS
# Copy the .cc file to the cargo project root to make it available
# to XCode
cp $(readlink target/cxxbridge/rust/src/lib.rs.cc) .. #Type a script or drag a script file from your workspace to insert its path.

Yeah I encountered this issue too. My solution was to add the flag in my build.rs file, that way we don't need to complicate the build phase script further. https://github.com/CommE2E/comm/blob/master/native/cpp/CommonCpp/grpc/grpc_client/build.rs#L5

In D4953#149055, @jon wrote:

We should probably use a build rule so that it doesn't need to blindly call this each time. But blindly calling it isn't too terrible as cargo builds should be relatively quick after initial build

yeah there's definitely some room for improving the script. i'd also like to use the target device to determine which arch to build for, rather than just always building a universal library

https://linear.app/comm/issue/ENG-1810/improve-rust-library-integration-in-xcode

follow ups for both marcin and tomek's comments tracked here ^