Add documentation for creating test dependencies.
Using `Package` has always been a little unclear to me. I think I understand
it now. Maybe this will help.
Only use non-absolute paths for `path` dependencies
Previously Cargo would use a non-absolute path for any dependency contained
within the workspace root but this switches Cargo to only using relative paths
for `path` dependencies. In practice this shouldn't make much difference, but
for vendored crates and moving around `CARGO_HOME` it can produce more
consistent results when target directories are shared.
Closes#5923
Previously Cargo would use a non-absolute path for any dependency contained
within the workspace root but this switches Cargo to only using relative paths
for `path` dependencies. In practice this shouldn't make much difference, but
for vendored crates and moving around `CARGO_HOME` it can produce more
consistent results when target directories are shared.
Closes#5923
- Use new enum `TargertSourcePath` for Target::src_path to make it explicit that metabuild has a special path.
- `cargo metadata` now skips the metabuild Target.
- JSON artifacts include the true path to the metabuild source file. This may not be the best solution, but it's unclear what it should be, and I would prefer to avoid breaking the output. Alternatively it could just not emit anything? I'm not completely familiar with the use case of these artifact messages.
- Place the file in `target/.metabuild/metabuild-pkgname-HASH.rs` instead of in the debug/release directory. Its contents do not depend on the profile.
- Fix bug in write_if_changed.
- More tests.
Make "cargo uninstall" uninstall the cwd bins
Fixes#5916
Tested with a local build of cargo, using coreutils:
17:33:57 $ dcargo uninstall
Removing /Users/dnw/.cargo/bin/uutils
fix cargo not doing anything when the input and output mtimes are equal
That's a problem as the input may have changed in that same second but after the output got generated!
Fixes https://github.com/rust-lang/cargo/issues/5918
Add `required-features` to `SerializedTarget`
This will add it to `cargo metadata` output and will make it
possible to enable features needed to build specific target.
Add a configuration option to fetch with git-the-CLI
Currently Cargo always uses `libgit2` to perform all fetches of git
repositories, but sometimes this is not sufficient. The `libgit2` library
doesn't support all authentication schemes that `git` does and it isn't always
quite at feature parity with `git` itself, especially in terms of network
configuration.
This commit adds a configuration option to Cargo for fetching git repositories
with the `git` CLI tool rather than the internal `libgit2`. While this exposes
us to changes over time in the `git` CLI it's hopefully a very targeted use case
that doesn't change much. The internal `libgit2` library should be sufficient
for all other forms of git repository management. (and using `git` for only
fetches shouldn't slow us down much)
The new configuration option in `.cargo/config` is:
[net]
git-fetch-with-cli = true
which can also be specified with `CARGO_NET_GIT_FETCH_WITH_CLI=true` via an
environment variable.
Closes#5903
Currently Cargo always uses `libgit2` to perform all fetches of git
repositories, but sometimes this is not sufficient. The `libgit2` library
doesn't support all authentication schemes that `git` does and it isn't always
quite at feature parity with `git` itself, especially in terms of network
configuration.
This commit adds a configuration option to Cargo for fetching git repositories
with the `git` CLI tool rather than the internal `libgit2`. While this exposes
us to changes over time in the `git` CLI it's hopefully a very targeted use case
that doesn't change much. The internal `libgit2` library should be sufficient
for all other forms of git repository management. (and using `git` for only
fetches shouldn't slow us down much)
The new configuration option in `.cargo/config` is:
[net]
git-fetch-with-cli = true
which can also be specified with `CARGO_NET_GIT_FETCH_WITH_CLI=true` via an
environment variable.
Closes#5903
Generate .cargo_vcs_info.json and include in `cargo package` (take 2)
Implements #5629 and supersedes #5786, with the following improvements:
* With an upstream git2-rs fix (tracked #5823, validated and min version update in: #5858), no longer requires windows/unix split tests.
* Per review in #5786, drops file system output and locks for .cargo_vcs_info.json.
* Now uses serde `json!` macro for json production with appropriate escaping.
* Now includes a test of the output json format.
Possible followup:
* Per discussion in #5786, we could improve reliability of both the VCS dirty check and the git head sha1 recording by preferring (and/or warning otherwise) the local repository bytes of each source file, at the same head commit. This makes the process more appropriately like an atomic snapshot, with no sentry file or other locking required. However given my lack of a window's license and dev setup, as exhibited by troubles of #5823, this feel intuitively like too much to attempt to change in one iteration here. I accept the "best effort" concept of this feature as suggested in #5786, and think it acceptable progress if merged in this form.
@alexcrichton r?
@joshtriplett cc
Update opener requirement from 0.2.0 to 0.3.0
Updates the requirements on [opener](https://github.com/Seeker14491/opener) to permit the latest version.
<details>
<summary>Changelog</summary>
*Sourced from [opener's changelog](https://github.com/Seeker14491/opener/blob/master/CHANGELOG.md).*
> ## [0.3.0] - 2018-08-18
> ### Added
> - `stderr` field to `OpenError::ExitStatus` variant, which captures anything the failed process wrote to stderr.
>
> ## [0.2.0] - 2018-08-08
> ### Removed
> - The `open_sys` function, which was erroneously pub on non-Windows builds.
>
> ## [0.1.0] - 2018-08-08
> - Initial release.
</details>
<details>
<summary>Commits</summary>
- See full diff in [compare view](https://github.com/Seeker14491/opener/commits/v0.3.0)
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot ignore this [patch|minor|major] version` will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme
Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Pull request limits (per update run and/or open at any time)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)
Finally, you can contact us by mentioning @dependabot.
</details>
.. with mutliple calls of:
fastmod --accept-all '\.cargo\("([^"]+)"\)\.arg\("([^"]+)"\)' '.cargo("${1} ${2}")' tests/testsuite/
until no changes are left.
