How do I set a Cargo project to build & run using nightly by default (i.e. cargo build is actually cargo +nightly build) without setting nightly as the global default?
This is not the same question as How to switch between Rust toolchains. If you read both questions you'll see that question is asking about switching Rust toolchains globally whereas I want to switch Rust toolchains without changing the global setting.
With rustup override set nightly it sets the default for that directory to nightly:
https://rust-lang.github.io/rustup/overrides.html#directory-overrides
If you want this choice to also be reflected in the repository, as opposed to just local configuration, you can add a rust-toolchain.toml file, for example
[toolchain]
channel = "nightly"
You might also want to set the nightly compiler's version (printed by rustup show) in the rust-version field of your cargo.toml, so that dependents which try to build on stable get an error message (since rust-toolchain.toml sets the version for a directory, not a crate).
Related
I use this kind of things:
#[cfg(feature = "myfeature")]
When I click "Build - Build Project" it calls cargo build. How can I specify that I want myfeature to be used? I found that I can specify it for my Run configuration but still it doesn't work for "Build".
On the command line, you'd use cargo build --features myfeature. In clion using the IntelliJ Rust plugin, you should be able to open the Cargo.toml file and tick the box next to the feature definition to enable it within the IDE, as demonstrated in this blog post.
Is it acceptable to register generally useful (utilities / applications) on crates.io?
The FAQ doesn't address this and from browsing, there are examples of end-user applications (mostly command line tools).
Or is crates.io? meant only for libraries?
I'm asking this because the documentation hints at library use, semantic versioning for API's etc. but doesn't reference the case for packaging applications explicitly.
Yes, because you can use cargo install to install and manage those applications system-wide. If this use were discouraged, I would suspect that command to not exist at all, or at least have a very limited applicability.
Snippet from cargo install --help:
Usage:
cargo install [options] [<crate>]
cargo install [options] --list
[...]
This command manages Cargo's local set of installed binary crates.
Only packages which have [[bin]] targets can be installed, and all
binaries are installed into the installation root's bin folder. The
installation root is determined, in order of precedence, by --root,
$CARGO_INSTALL_ROOT, the install.root configuration key, and
finally the home directory (which is either $CARGO_HOME if set or
$HOME/.cargo by default).
There are multiple sources from which a crate can be installed. The
default location is crates.io but the --git and --path flags can
change this source. If the source contains more than one package (such
as crates.io or a git repository with multiple crates) the <crate>
argument is required to indicate which crate should be installed.
This should not be the primary reason to publish an application to crates.io, but I'm listing it here because it's still a good reason. :)
The Rust team will occasionally use a tool called crater to check for regressions on all crates published on crates.io, usually before merging a pull request that has uncertain consequences. If you wrote some code that happens to compile today but would stop compiling1 due to a bug fix in the compiler, then they may even submit a pull request to your project that fixes your code!
1 Usually, when such breaking changes occur, there's at least one prior release in which a warning will be reported before the warning is turned into an error.
I installed the multirust version of the Rust programming language. I was trying to configure the racer code completion package to point to the Rust source code through the RUST_SRC_PATHenvironment variable. However, I can't seem to find the location of the rust source files. When I type which rustc I am pointed to /usr/local/bin probably because there is a symlink to the actual source directory or something. Any info on where the proper directory for the RUST_SRC_PATH variable is for multirust?
By default, rustup doesn't install the source code for the Rust standard library. But you can execute the following command to install it:
$ rustup component add rust-src
The source is installed in ~/.rustup/toolchains/$TOOLCHAIN/lib/rustlib/src/rust/src/ (where $TOOLCHAIN is the name of a toolchain you use).
Currently, multirust doesn't install the source. This is also mentioned in the context of using racer with multirust.
Instead, follow the instructions in the Racer README:
Fetch the Rust sourcecode from git, or download from https://www.rust-lang.org/install.html
I've finally started to dive into Rust and want to clarify some issues when it comes to setting up everything nicely.
I'm using vim on Linux and found a nice plugin for syntax highlighting. Autocompletion is somewhat troublesome though, using phildawes/racer.
The plugin needs the src location for Rust which is in fact not that big of a deal, if I would know where said directory was (I only found the binaries and libs when using the suggested curl <...> | sh install). The sources are downloadable separately, although I didn't find an install for Rust that sets up the sources in let's say e.g. /usr/local/src/rust only the binaries and libs.
Second I've looked through the Cargo docs and and didn't find anything to where the extern dependencies are cloned into (wouldn't this be the source directory?)
Also should the Rust sources be updated setting up everything manually is kind of lame?
Is the quintessence to clone the Rust repository and build it yourself?
The plugin needs setting up the src location for rust which is in fact not that big of a deal, if I would know where said directory was
I couldn't find the sources either. If you just want the sources without all the history:
For 1.0.0,
git clone --depth=1 --branch 1.0.0 --single-branch https://github.com/rust-lang/rust/
or for nightly
git clone --depth=1 --single-branch https://github.com/rust-lang/rust/
Second I've looked through the cargo docs and and didn't find anything to where the extern dependencies are cloned into (wouldn't this be the source directory?)
In the standard installation, there's a directory .cargo in your home directory, which contains git/checkouts for the cloned crates.
You should probably try multirust though, which allows you to easily manage multiple Rust installations in ~/.multirust.
With multirust, your crate checkouts might be in e.g. ~/.multirust/toolchains/nightly/cargo/git/checkouts, not ~/.cargo/git/checkout.
Is the quint essence to clone the rust repository and build it yourself?
No, that's luckily not necessary anymore, unless you're working on the compiler/stdlibs, or trying to cross-compile. With multirust, updating is reduced to multirust update or multirust update nightly, etc.
Existing build systems usually have some kind of install targets, that is used either manually (for installing in /usr/local or other location that user can access) or automatically (by package build systems of binary based distros or by package managers of source based ones).
What is the intended way of installing software that uses Cargo? How an analog of make install should look like?
Cargo itself uses additional configure/make stuff that handles configuration, detection of system dependencies, running cargo build and installation.
Is this the right way for any other software built with Cargo? It means are there plans to cover this tasks by Cargo itself or is Cargo intended only as a tool for dependency fetching and compilation without any configuration/detection of installed deps/installation?
Or are any plans to add this functionality?
cargo install
As of Rust 1.5 you can use cargo install to install binary crates onto your system. You can install crates from:
crates.io (the default), using cargo install crate_name
any git repository, using cargo install --git repository_url
any directory, using cargo install --path /path/to/crate
The first two have additional options you can specify:
With crates.io, you can use --vers to specify the crate version.
With git repositories, you can use --branch to set the branch to install from, --tag to specify the tagged release to use, and --rev to build from a specific commit.
Installation location:
cargo install can be configured to install in a custom directory through the following methods, in order of precedence (highest first):
By passing --root /path/to/directory (this path can be relative)
By setting the $CARGO_INSTALL_ROOT environment variable
By setting the install.root configuration key
By setting the $CARGO_HOME environment variable (which will affect more than the installation directory of cargo install)
If none of the above are present, cargo will install the crates in ~/.cargo/bin.
In all of the above cases, the output files will actually be placed in the bin subdirectory (e.g. --root /path/to/directory will actually place ouput in /path/to/directory/bin).
Uninstallation
cargo uninstall can be used to remove previously-installed crates. If you have multiple crates with the same name installed, you can specify --root to only remove the version in that directory.
Example: I want to use rustfmt:
I can use the version on crates.io:
cargo install rustfmt
I like using original releases:
cargo install rustfmt --vers 0.0.1
I want it installed in /opt/rust_crates:
cargo install rustfmt --root /opt/rust_crates
I really need to use the bleeding-edge version:
cargo install --git https://github.com/rust-lang-nursery/rustfmt.git
The latest commit has a bug in it!
cargo install --git https://github.com/rust-lang-nursery/rustfmt.git --rev f5bd7b76e0185e8dd37ae6b1b5fb5e11187f0b8c
I truly desire the version that uses git submodules for its dependencies:
cargo install --git https://github.com/rust-lang-nursery/rustfmt.git --branch submods
I've cloned it and made some edits:
cargo install --path ~/my_rustfmt
Actually, I insist on doing my formatting entirely manually:
cargo uninstall rustfmt
(This answer is intended for developers who want to distribute their own programs, not users who have received a Cargo project and need to install it on their own system; That's the domain of Toby's answer).
In addition to Toby's Answer:
Cargo's install feature is not meant to be the primary way to distribute Rust programs. It's designed to be used only for distribution to other Rust developers. There's several drawbacks to using this feature:
Cargo requires end-users to install the entire Rust toolchain first.
Users will have to build the program locally, which can be slow, especially in Rust.
There's no support for upgrading programs once they're installed (without an additional tool).
There's (currently) no way to include assets, such as documentation.
The packages will be installed only for the current user unless flags are passed to cargo install.
In other words, cargo install is the make && sudo make install of Cargo programs; It's not the ideal way to distribute a Rust program, unless it's intended primarily for Rust programmers.
So what is the correct way?
Let's look at the alternatives.
Manually distribute a tarball/zip
You can replicate the effects of cargo install by simply using cargo build --release. This will place a (mostly, see the drawbacks below) statically linked crate binary in target/release/crate_name, and this can be repackaged into a .tar.gz or .zip and given out to other users.
Pros:
Doesn't require users to install Rust or build the program themselves.
Allows developers to copy assets into the tarball/zip and distribute them along with the program itself.
Cons:
Installing a .tar.gz/.zip is nonstandard and generally not considered ideal for most users.
If the crate needs any system dependencies beyond libc, it will fail to load them with a difficult to understand error.
This requires a developer to manually build a package to release for each version and platform combination.
Use a CI service to build releases
It's possible to recreate any of these methods using a cloud-based CI service. For example, using Travis CI, you can use the Trust project to automatically deploy in much the same way that you would from a tarball, but automatically with only a tag being required.
Pros:
(All of the advantages of a tarball, plus)
The developers don't have to manually release the program, they just need to tag a release.
As a side effect, it's possible to build for every package the program supports at once.
Cons:
The process can be frustrating to debug if it doesn't work correctly, because there's limited control over the server.
The build process is tied to a service, which means releases can be missed if the service is down when they are released.
With Trust or similar tools, you're still ultimately distributing a .tar.gz/.zip, which means there's still inconvenience for users and a lack of system dependency management.
In addition to Travis, see Appveyor and GitHub Actions as possible build platforms.
Provide a package
This is considered the ideal method for many end users, and is the standard way to distribute any program, not just Cargo programs. This alleviates almost every issue with the tarball approach, though not without some problems of its own.
Pros:
Included in the system like any other program.
Can be submitted to Linux distribution repositories to allow programs to be installed in only one command.
Allows updating, removal, and asset inclusion.
Tracks system dependencies, which is especially helpful for GUI apps.
Cons:
By far the most complex of these options.
Requires building a package separately for every supported platform (this can be alleviated with CI, but it will be even more complex to setup this way.)
This approach is best handled with additional tools:
cargo-deb: Build a package for Debian and Ubuntu.
cargo-rpm: Build a package for Fedora, Red Hat, and CentOS.
cargo-aur: Build a package for Arch Linux.
cargo-wix: Make a Windows Installer package.
These usually are tools that are meant to be run by developers, to create the files that are used to generate packages. See their own documentation for more information.
Source: https://rust-cli.github.io/book/tutorial/packaging.html