- cargo update
- But stay on our fork of curve25519-dalek (pinned at 3.0.0)
- Update x25519-dalek from 1.0 to 1.1 (instead of 1.2) to stay
compatible with curve25519-dalek
- Update cpufeatures to 2.1 to match our dependencies
- Note that updating picky* resulted in more duplicate crates (rand*)
- Pin num-bigint-dig to a build that supports Cargo's -Zbuild-std,
because xargo + autocfg has stopped working with the new toolchain
- Remove xargo in favor of -Zbuild-std
Also, if the library somehow isn't built when used as a non-local
CocoaPods dependency, don't suggest running swift/build_ffi.sh;
CocoaPods will have removed it already. Re-running `pod install` is
more likely to help, though in practice something's probably gone
wrong in the configuration.
The most common manual invocation of this script is when developing
using the local Swift package, not building a library to publish as an
CocoaPods artifact. The most common command should be easiest.
Also, update the Swift README to match the CocoaPods build process
added in b061e84189.
The mistakes with the curve25519-dalek update means that 0.3.0 no
longer builds correctly. Use 0.3.1 instead.
Changes from 0.1.2 (the version before 0.3.0):
- Reject SenderCertificates without UUIDs
- Fix IdentityKeyPair.init(bytes:)
- Add logging to match SignalProtocolKit
- Update Cargo dependencies to newer versions
This is an alternate approach to using cocoapods-binary that allows
the Swift code to be built on the app side, avoiding some LLDB/Swift
integration issues.
The plugin we use for prebuilding CocoaPods, cocoapods-binary, still
allows Pods to add script phases to the final build...but we don't
actually *want* to run our build script when the pod is prebuilt.
This makes the CocoaPod self-contained at the cost of using a module
layout that SwiftPM cannot replicate. To keep local SwiftPM builds
working, an unstable Swift compiler flag is used to auto-import a
separate SignalFfi module (the way it used to work).
- Verify its correctness with build_ffi.sh --verify-ffi
- Regenerate with build_ffi.sh --generate-ffi
This simplifies the header search logic for both SwiftPM and
CocoaPods, as well as saving on build time by avoiding cbindgen.
The tweak to cbindgen.toml to prefer typedef-based structs and enums
is sidestepping an incompatibility between cbindgen 0.15.0 (which
GitHub has installed) and 0.16.0 (which allows reusing a release build
directory as well as a debug one).
We're not actually logging anything yet, but this will let us do so.
The logging is initialized using a static constructor so that clients
of SignalCoreKit don't have to do any additional setup. This requires
an ObjC file instead of a Swift one. (When running as a Swift package,
logs will just go to stderr via NSLog.)
