updating UniFFI to 0.26.1 (latest)

[heckj]

• updated to UniFFI 0.26.1 (latest)
• resolve build failures after updating (currently a linking error)

fixes #38

[heckj]

@Horusiath, @nugmanoff Just a quick progress note: the UniFFI side doesn't seem to be an issue at all with an update to 0.26.1, but the swift build is failing when it goes to link with unknown symbols. UniFFI generates a swift file alongside it's work, so my first suspicion is that we're not coping/using the generated version correctly, but I haven't yet sat down and really tracked what's happening.

Gist so far:

• updated Uniffi to 0.26.1
• updated Yrs to 0.17.4

./scripts/build-xcframework.sh completes without issue, but the following swift build command (with export YSWIFT_LOCAL=1 to make sure it uses the rebuilt XCFramework) is failing to link

errors: https://gist.github.com/heckj/63edda527fa7e0476762a34dc5f54ab2

The errors are all in Yniffi, and across all the "types" we exposed to work with.

I'll continue digging tomorrow, but wanted to let you know progress.

[heckj]

turns out the way we had set up the cargo calls to run bindgen had two different Cargo.toml files, and the one with bindgen hadn't been updated. Since I saw how it was arranged at the Automerge, which had a single Cargo.toml, that seemed a better way to get this operational, so I switched to that pattern, which resolved the issues I was seeing with linking - bindgen was basically being called with a conflicting version, which caused havoc.

This should be more robust down the road - but cargo run and that whole space is not my expertise, so if there's room for improvement here, I'm all ears.

Locally, this passed the build & test sequence across the board.

There are still sendable warnings being generated, which do need to be dealt with at some point - but seemed almost better to review externally to this.

[heckj]

Oh damnit! We're back to CI failing with the tuist setup. I'll focus on doing something about that tomorrow.