resolver V2 kills this guarantee! That's ok, at least the CLI/new post-build package can check an exported version string from its dep and tell you when there's a mismatch.) Using the crate graph to do this seems good. Re wasm-bindgen, this solves the problem that wasm-pack was invented to solve, namely having an on-demand binary wasm-bindgen-cli with the exact same version number as the wasm-bindgen whose macros were used in the crate.Just have a crate that runs lipo and let the community figure it out. Post build scripts via crates with binaries would eliminate the need for builtin steps like "lipo".there are, however, a lot of cargo wrappers out there that could really just work in this position.That seems like a lot of work? Unless all they need to do is have a binary target that is executed as if it's a normal post-build script. probably need a way for build-dependencies to extend the list of builtin post processing steps.can you use this to implement wasm-pack/ wasm-bindgen's post processing?.do you add these fields to the section directly as well? Probably yes?.big remaining question is how you activate this custom configuration from the command line.obviously doesn't apply to rlib crate-type outputs, which you can't do post processing on.Xcode actually doesn't call lipo - it uses libtool (not the GNU one) to do this job.
But I like that you can let people use their own tool for it.
Do you want to share those two? Probably fine not so DRY but fine.
do we need this outside the lib target configuration? Probably yes, the bin target as well.# or supply a list of builtin post-processing steps. # Then you can use this for arbitrary post-processing including strip, etc. # and either post-build = "lipo_universal.rs " # runs lipo on the outputs that it reads from env variables.
#Rust for mac free install#
I don't think we need to go through all this trouble, a first improvement to include the functionality from cargo-lipo directly into cargo while relying on the presence of a "lipo" command-line tool (we could support it on Linux if you install the cctools-port) would already be more than good enough. There exists a Linux port of cctools with a copy of lipo I have successfully used myself: This tool is open sourced by Apple as part of the cctools package, but they never bothered porting it to other platforms themselves. The only downside is that this won't solve the problem of cross-compiling, but there are many other issues that make this quite difficult anyway, starting by the availability of tools like "lipo" outside of Xcode on macOS. Under the hood all it does is build for each target + combine the multiple thin binaries into a single fat binary using lipo. I think the current cargo-lipo solution could simply be ported directly into cargo instead of being a separate tool: basically keep building for one target at a time, but make it possible to call cargo telling it to build for multiple targets and produce universal binaries.
Without building Universal binaries this becomes half-built, and insufficient for macOS I second this, we shouldn't add a "universal" target, because it just makes everything much more complicated, without considering the fact that "universal" is not even a target, and could mean more than one thing (it is a combination of multiple targets, but we don't know which ones). There's a huge value in cargo build -release working for projects out of the box.Even if Cargo did have post-build steps, it would be chore to re-add the same necessary step to every project.That issue has been in limbo for years, but arm64 (M1) Macs have already shipped, and support for Universal binaries is needed right now. Cargo lacks support for general-purpose post-linking steps ( Post-build script execution #545).For the next 3-5 years it will be a necessary operation for every macOS release build.I think it support for universal binaries should be built-in in Cargo: In the debug mode, like Cargo, Xcode builds only the current native architecture.Ĭould cargo -release on macOS hosts automatically build both x86_64-apple-darwin and aarch64-apple-darwin, and merge them into a single executable? Merging requires running lipo -create -output universalbinary intelbinary armbinary. Apple is migrating from x86_64 to aarch64 CPUs, so for the next few years it will be important for macOS developers to build "fat" binaries (executables and cdylibs).Īpple's Xcode has very helpful default behavior for this: when building in release mode, it automatically builds for both x86_64 and aarch64 together.
#Rust for mac free code#
MacOS (and iOS) has a concept of universal binaries which contain code for multiple CPU architectures in the same file.