-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make binary installers for mac and linux #9876
Comments
Nominating. |
1.0, high |
Debian is tracking rust status to try to provide a proper package when it's time (ie. not now), some notes are at https://wiki.debian.org/Teams/RustPackaging |
rust port is already part of MacPorts. |
Work toward #9876. This adds `prepare.mk`, which is simply a more heavily-parameterized `install.mk`, then uses `prepare` to implement both `install` and the windows installer (`dist`). Smoke tested on both Linux and Windows.
What's the final decision here based on the latest discussion that happened on mailing list? It'd be nice to have a list of things that should happen to consider this bug completed:
As mentioned in #12546 (and on the mailing list thread) I'd prefer not having any distro specific packaging support as part of Rust's build system. I think the community will take care good care of that. |
Work towards #9876. Several minor things here: * Fix the `need_ok` function in `configure` * Install man pages with non-executable permissions * Use the correct directory for man pages when installing (this was a recent regression) * Put all distributables in a new `dist/` directory in the build directory (there are soon to be significantly more of these) Finally, this also creates a new, more precise way to install and uninstall Rust's files, the `install.sh` script, and creates a build target (currently `dist-tar-bins`) that creates a binary tarball containing all the installable files, boilerplate and license docs, and `install.sh`. This binary tarball is the lowest-common denominator way to install Rust on Unix. We'll use it as the default installer on Linux (OS X will use .pkg). ## How `install.sh` works * First, the makefiles (`prepare.mk` and `dist.mk`) put all the stuff that needs to be installed in a new directory in `dist/`. * Then it puts `install.sh` in that same directory and a list of all the files to install at `rustlib/manifest`. * Then the directory can be packaged and distributed. * When `install.sh` runs it does some sanity checking then copies everything in the manifest to the install prefix, then copies the manifest as well. * When `install.sh` runs again in the future it first looks for the existing manifest at the install prefix, and if it exists deletes everything in it. This is how the core distribution is upgraded - cargo is responsible for the rest. * `install.sh --uninstall` will uninstall Rust ## Future work: * Modify `install.sh` to accept `--man-dir` etc * Rewrite `install.mk` to delegate to `install.sh` * Investigate how `install.sh` does or doesn't work with .pkg on Mac * Modify `dist.mk` to create `.pkg` files for all hosts * Possibly use [makeself](http://www.megastep.org/makeself/) to create self-extracting installers * Modify dist-snap bots run on mac as well, uploading binary tarballs and .pkg files for the four combos of linux, mac, x86, and x86_64. * Adjust build system to be able to augment versions with '-nightly' * Adjust build system to name dist artifacts without version numbers e.g. `rust-nightly-...pkg`. This is so we don't leave a huge trail of old nightly binaries on S3 - they just get overwritten. * Create new dist-nightly builder * Give the build master a new cron job to push to dist-nightly every night * Add docs to distributables * Update README.md to reflect the new reality * Modernize the website to promote new installers
Closing, @brson has done some awesome work recently, and we have binary installers forth both these platforms. They're even in nightly form! |
We need the installation experience to be very easy everywhere. Currently we require unixes to build from source, but that shouldn't be strictly necessary - we already distribute snapshot binaries that work.
Add a new build target that creates a binary installer similarly to the snapshots.
The text was updated successfully, but these errors were encountered: