#Rust for mac m1 full
#Rust for mac m1 android
#Rust for mac m1 code
#Rust for mac m1 series
#Rust for mac m1 simulator

That still leaves Rust behind, as it doesn't know the new -simulator target.īut as always the Rust community is ahead of the game and deg4uss3r started adding a new target in Rust PR #81966.

That's what Carthage and others stumbled over.Īgain Apple prepared for that and for a long time they have wanted you to use XCFramework bundles 6.Ĭarthage just didn't used to support that.

#Rust for mac m1 code

You still can't put code compiled for arm64-apple-ios and arm64-apple-ios14.0-simulator into the same universal binary 5,īecause you can have each architecture only once (the arm64 part in there). The compiler knows from where to pick the libraries and other SDK files when using that target. So the compiler toolchain gained knowledge of a new thing: arm64-apple-ios14.0-simulator, Now Xcode and the compiler will get confused what to put where when building on M1 hardware for both iOS hardware and the host architecture.

#Rust for mac m1 simulator

The iOS simulator run on these machines would also be aarch64 4,Īnd also contain ios, but not be for the iOS hardware. With the introduction of Apple Silicion 3 So when the compiler saw x86_64 and iOS it knew 'Ah, simulator target'Īnd when it saw aarch64 and ios it knew 'Ah, hardware'.Īnd everyone went with this, Xcode happily built both targets and, if asked to, was able to bundle them into one package. When compiling for the iOS simulator you would pick a target named x86_64-apple-ios,īecause conveniently the simulator uses the host's CPU (that's what makes it fast).iPhones and iPads are ARM-based since forever. When compiling for iOS hardware you would pick a target named aarch64-apple-ios,īecause.That caused quite some issues with existing tooling, such as the dependency manager Carthage. Thus Xcode gained aarch64 support in version 12 long before the hardware was available. Their new machines should become the main machine people do iOS development on. Now we're getting to the interesting part: Native iOS development on an M1.

It's usable enough for some testing, but for that part I most often switch back to my Linux Desktop (that has the additional CPU power on top).

#Rust for mac m1 android

The default Android emulator isn't usable on M1 hardware yet, but Google is working on a compatible one: Android M1 emulator preview. A friend managed to compile and run that library on an M1.īut for Glean development we simply recommend relying on Rosetta 2 (the x86_64 compatibility layer) for now.Īt least if you have Java set up correctly. Some of our transitive dependencies are based on years-old pre-built binaries of SQLiteĪnd of course there's not much support behind updating those Java libraries. Glean Android is not that straight forward.

#Rust for mac m1 full

So it's both possible to develop & test Glean Python, as well as use it as a dependency without having a full Rust development environment around. My colleague glandium later contributed support code so we build release wheels for that target too. It gained aarch64 2 macOS support in v14.4.1. We use cffi to load the native library into Python. This landed in August and was promoted to Tier 2 1 with the December release of Rust 1.49.0.īy the time I got my MacBook compiling Rust code on it was as easy as on an Intel MacBook.ĭevelopers on Intel MacBooks can cross-compile just as easily: rustup target add aarch64-apple-darwinĬargo build -target aarch64-apple-darwin See Rust issue 73908 for all the work and details.įirst and foremost this required a new target: aarch64-apple-darwin. Work on getting Rust compiled on M1 hardware started last year in June already, with the availability of the first developer kits.

Stretch goal: Get iOS projects using Glean running as well.

Build & test the Swift language bindings natively and in the iPhone simulator on an M1 machine.

Build & test the Kotlin & Swift language bindings on an M1 machine, even if non-native (e.g.

Compile the Rust portions of Glean natively on an M1 machine.

We maintain a Swift language binding, targeting iOS, and that one is used in Firefox iOS.Įventually these iOS developers will also have M1-based machines and want to test their code, thus Glean needs to work. I got it with the explicit task to ensure that we are able to develop and build Glean on it. This article is cross-posted on the Mozilla Data blog. They could be release notes, documentation, hopes, dreams, or whatever: so long as it is inspired by Glean.)Īll 'This Week in Glean' blog posts are listed in the TWiG index

#Rust for mac m1 series

(“This Week in Glean” is a series of blog posts that the Glean Team at Mozilla is using to try to communicate better about our work.