Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project.
is_build==false <-> ProjectBuilder
is_build==true <-> Project
Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project.
The same goes for RepoBuilder.
ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability.
Signed-off-by: NODA, Kai <nodakai@gmail.com>
This renames the debug target to dev in the build output for non-release
builds. This includes the output of commands such as `cargo build`,
`cargo test`, and `cargo doc`.
Closes#3519
Always pass `-C metadata` to the compiler
If it's not otherwise available we just key it off the pkgid which should be
unique enough across compilations. This should help incremental compilation
efforts be "more incremental" across projects.
Closes#2943
If it's not otherwise available we just key it off the pkgid which should be
unique enough across compilations. This should help incremental compilation
efforts be "more incremental" across projects.
Closes#2943
This commit implements a scheme for .cargo/config files where sources can be
redirected to other sources. The purpose of this will be to override crates.io
for a few use cases:
* Replace it with a mirror site that is sync'd to crates.io
* Replace it with a "directory source" or some other local source
This major feature of this redirection, however, is that none of it is encoded
into the lock file. If one source is redirected to another then it is assumed
that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in
both location). The lock file simply encodes the canonical soure (e.g.
crates.io) rather than the replacement source. In the end this means that
Cargo.lock files can be generated from any replacement source and shipped to
other locations without the lockfile oscillating about where packages came from.
Eventually this support will be extended to `Cargo.toml` itself (which will be
encoded into the lock file), but that support is not implemented today. The
syntax for what was implemented today looks like:
# .cargo/config
[source.my-awesome-registry]
registry = 'https://example.com/path/to/index'
[source.crates-io]
replace-with = 'my-awesome-registry'
Each source will have a canonical name and will be configured with the various
keys underneath it (today just 'registry' and 'directory' will be accepted). The
global `crates-io` source represents crates from the standard registry, and this
can be replaced with other mirror sources.
All tests have been modified to use this new infrastructure instead of the old
`registry.index` configuration. This configuration is now also deprecated and
will emit an unconditional warning about how it will no longer be used in the
future.
Finally, all subcommands now use this "source map" except for `cargo publish`,
which will always publish to the default registry (in this case crates.io).
Previously Cargo would compile a library into a different location depending on
whether it was the "root crate" or not. In the ongoing saga of reducing Cargo's
reliance on the idea of a "root crate" this PR is the next step. With workspaces
the root crate of a compliation changes all the time, so the output needs to be
the same whether a crate is at the root or not.
Fixing this inconsistence in turn fixes bugs like #2855 and #2897 which arise
due to this discrepancy. Additionally, Cargo will no longer recompile a library
when it's used as a "root crate" or not.
This is fixed by taking a few steps:
* Everything is now compiled into the `deps` directory, regardless of whether
it's a root output or not.
* If a "root crate" is being compiled, then the relevant outputs are hard-linked
up one level to where they are today. This means that your binaries, dylibs,
staticlibs, etc, will all show up where they used to.
* The `-C metadata` flag is always omitted for path dependencies now. These
dependencies are always path dependencies and already all have unique crate
names. Additionally, they're the only crates in the DAG without metadata, so
there's no need to provide additional metadata. This in turn means that none
of the file names of the generated crates are mangled.
Closes#2855
Dearest Reviewer,
This pull request closes#1091 which is a request to support aliases.
This is not as powerful as something like git's alias, however, I think
it sticks true to the original request.
I high jack the processing of the args. After a few flags are checked
and the args are parsed I check the config file for alias.COMMAND. If it
is there I split it like args does and replace args[1] (the original
command) with the alias command and its 'flags'.
I have also included default short hand commands b, t and r.
Thanks!
Becker
