Auto merge of #2811 - alexcrichton:network-is-error, r=brson
Add a flag to force network access to be an error
If a lock file is generated and some equivalent of `cargo fetch` is run then
Cargo shouldn't ever touch the network or modify `Cargo.lock` until any
`Cargo.toml` later changes, but this often wants to be asserted in some build
environments where it's a programmer error if Cargo attempts to access the
network.
The `--locked` flag added here will assert that `Cargo.lock` does not need to
change to proceed. That is, if `Cargo.lock` would be modified (as it
automatically is by default) this is turned into a hard error instead.
This `--frozen` will not only assert that `Cargo.lock` doesn't change (the same
behavior as `--locked`), but it will also will manually prevent Cargo from
touching the network by ensuring that all network requests return an error.
These flags can be used in environments where it is *expected* that no network
access happens (or no lockfile changes happen) because it has been pre-arranged
for Cargo to not happen. Examples of this include:
* CI for projects want to pass `--locked` to ensure that `Cargo.lock` is up to
date before changes are checked in.
* Environments with vendored dependencies want to pass `--frozen` as touching
the network indicates a programmer error that something wasn't vendored
correctly.
A crucial property of these two flags is that **they do not change the behavior
of Cargo**. They are simply assertions at a few locations in Cargo to ensure
that actions expected to not happen indeed don't happen. Some documentation has
also been added to this effect.
Auto merge of #2893 - KasMA1990:patch-1, r=alexcrichton
Include reference to Rust code structuring
Hey guys, I'm proposing this little addition to the manifest. When I first started with Rust, I wanted to make a simple crate, so the "Getting Started" (and from there, the manifest) document on crates.io was a natural entry point for me. However, it would have helped getting over some headaches initially if the Cargo documentation had driven me into the relevant Rust documentation; in the beginning at least it wasn't clear to me where Cargo ended and Rust began, especially with modules.
I'm not sure if this should be in the actual manifest or in the "Getting Stated" doc, or if you want it there at all, but it's a quality-of-life thing that I think past-me would have appreciated at least :)
Alex Crichton [Tue, 28 Jun 2016 17:39:46 +0000 (10:39 -0700)]
Add flags to assert lock/cache behavior to Cargo
If a lock file is generated and some equivalent of `cargo fetch` is run then
Cargo shouldn't ever touch the network or modify `Cargo.lock` until any
`Cargo.toml` later changes, but this often wants to be asserted in some build
environments where it's a programmer error if Cargo attempts to access the
network.
The `--locked` flag added here will assert that `Cargo.lock` does not need to
change to proceed. That is, if `Cargo.lock` would be modified (as it
automatically is by default) this is turned into a hard error instead.
This `--frozen` will not only assert that `Cargo.lock` doesn't change (the same
behavior as `--locked`), but it will also will manually prevent Cargo from
touching the network by ensuring that all network requests return an error.
These flags can be used in environments where it is *expected* that no network
access happens (or no lockfile changes happen) because it has been pre-arranged
for Cargo to not happen. Examples of this include:
* CI for projects want to pass `--locked` to ensure that `Cargo.lock` is up to
date before changes are checked in.
* Environments with vendored dependencies want to pass `--frozen` as touching
the network indicates a programmer error that something wasn't vendored
correctly.
A crucial property of these two flags is that **they do not change the behavior
of Cargo**. They are simply assertions at a few locations in Cargo to ensure
that actions expected to not happen indeed don't happen. Some documentation has
also been added to this effect.
Auto merge of #2891 - upsuper:fix-search-path, r=alexcrichton
Search dylib path from cargo before system
Cargo should have more knowledge about what it is looking for, and thus its paths should be more correct compared to system's. When there are conflicts, the search paths provided by the build system should take priority.
Xidorn Quan [Mon, 18 Jul 2016 07:25:22 +0000 (17:25 +1000)]
Search dylib path from cargo before system
Cargo should have more knowledge about what it is looking for, and thus
its paths should be more correct compared to system's. When there are
conflicts, the search paths provided by the build system should take
priority.
Auto merge of #2849 - wezm:publish_dry_run, r=alexcrichton
Add --dry-run to cargo publish
This PR picks up where @JustAPerson left off in https://github.com/rust-lang/cargo/pull/1699. I've updated their changes to apply to current master and added tests, including (I think) a test that checks that the upload doesn't actually occur.
Auto merge of #2887 - wuranbo:doc-explain-doublebrackets, r=alexcrichton
doc: manifest.md add explain about double-bracket
Add TOML doc ref to explain double-bracket sections like [[bin]].
It really confused me when I saw the double-bracket first. I search google, take some time, and then saw the TOML doc, recall that we can have more than one executable in Cargo, understood it. So it can be added to help someone like me (:
Auto merge of #2870 - matklad:add-host-triple, r=alexcrichton
Refactor `host/target_triple` handling
This PR adds an explicit `host_triple` filed to `BuildConfig`. It allows to unify host and target handling and to reduce the number of accesses to `config.rustc_info()`. As a side effect, the explicit `target_triple` field of `Context` is gone because it can now be calculated from the `BuildConfig`.
Auto merge of #2679 - sbeckeriv:alias, r=alexcrichton
Command alias or Alias command #1091
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'.
As an extra measure I output the alias command with warn. I would be
willing to drop that or put it behind a verbose flag. Also the docs have
been updated.
Auto merge of #2863 - QuiltOS:specified-req, r=alexcrichton
Make the `DependencyInner::specified_req` field a bool.
I could almost get rid if it completely, but then the dependency verifier would have to abort on, say, no version req specified or the any req. Crates.io indeed doesn't want wildcards, but other registries some day may have a different policy.
Making it a mere bool---since all the information it contained is on the `req` field anyways---was the next best thing.
John Ericson [Tue, 12 Jul 2016 16:55:02 +0000 (09:55 -0700)]
Make the `DependencyInner::specified_req` field a bool.
This field is hardly used. I could almost get rid if it completely, but
then the dependency verifier would have to abort on, say, no version req
specified or the any req. Crates.io indeed doesn't want such wildcards, but
other registries some day may have a different policy.
Making it a mere bool---since all the information it contained is in the
`req` field anyways---was the next best thing.
Auto merge of #2853 - matklad:reduce-duplication, r=alexcrichton
Reduce duplication in `Context` creation
There was some duplicated code for `Context` creation in `cargo_clean` and `cargo_rustc`. I've tried to remove it by moving the common part into `Context::new`. Not sure that this is the right thing to do though, it's just something I came across while tracing `rustc_info` flow.
Additional possible refactoring would be to remove `Default` bound from `BuildConfig`.
Auto merge of #2839 - alexcrichton:same-root, r=brson
Generate the same lock always in a workspace
Previously the "root" of a lock file would erroneously change over time, so
instead just ensure that the root of a lock file is always the root of the
workspace. Otherwise the contents should always be the same.
Alex Crichton [Fri, 8 Jul 2016 06:11:22 +0000 (23:11 -0700)]
Generate the same lock always in a workspace
Previously the "root" of a lock file would erroneously change over time, so
instead just ensure that the root of a lock file is always the root of the
workspace. Otherwise the contents should always be the same.
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.
Auto merge of #2828 - bennofs:cargo-repackage, r=alexcrichton
cargo package: overwrite existing tarballs
Previously, cargo package did not do anything if a tarball already
existed. This is wrong, because the source may have changed and cargo
does not do any dependency tracking for package tarballs yet, so it did
not notice this.
This commit changes cargo package to always overwrite existing tarballs,
which works fine until proper dependency tracking is implemented.
Previously, cargo package did not do anything if a tarball already
existed. This is wrong, because the source may have changed and cargo
does not do any dependency tracking for package tarballs yet, so it did
not notice this.
This commit changes cargo package to always overwrite existing tarballs,
which works fine until proper dependency tracking is implemented.
A workspace is a group of crates which are all compiled into the same output
directory and share the same `Cargo.lock` file. This means that dependencies are
cached between builds as well as dependencies all being shared at the same
versions. An update to any one dependency transitively affects all other members
of the workspace.
Typical repository layouts with a crate at the root and a number of path
dependencies simply need to add the following to the root `Cargo.toml`:
```toml
[workspace]
```
Otherwise more advanced configuration may be necessary through the
`package.workspace` or `workspace.members` keys. More information can be found
as part of [RFC 1525].
A workspace is a group of crates which are all compiled into the same output
directory and share the same `Cargo.lock` file. This means that dependencies are
cached between builds as well as dependencies all being shared at the same
versions. An update to any one dependency transitively affects all other members
of the workspace.
Typical repository layouts with a crate at the root and a number of path
dependencies simply need to add the following to the root `Cargo.toml`:
```toml
[workspace]
```
Otherwise more advanced configuration may be necessary through the
`package.workspace` or `workspace.members` keys. More information can be found
as part of [RFC 1525].
Auto merge of #2821 - bennofs:no-transitive-dep-feature, r=alexcrichton
Disallow specifying features of transitive deps
Before this commit, it was possible to activate a feature in a transtive
dependency, using a Cargo.toml like the following one:
...
[features]
# this will enable feature fast in package bar, which is a
# dependency of foo
default = [ foo/bar/fast ]
This is a bug, and was never intended, and it is checked in other places
already. The behavior was possible because `build_features::add_feature`
treats the specification "foo/bar/fast" as just another feature. So when
we require the feature "foo/bar/fast", add_feature for foo will generate a
dependency on "foo" requiring that feature "bar/fast" is enabled. Then,
when resolving foo, add_feature will find that "bar/fast" is a required
feature, so it'll happily add "fast" as the required feature for the
dependency "foo".
The fix for this is to make sure that the `add_feature` function does
not treat `a/b` specifications as just another feature. Instead, it now
handles that case without recursion directly when it encounters it.
We can see how this resolves the above problem: when resolving foo,
add_feature for the required feature "bar/fast" will be called.
Because add_feature no longer treats such specifciations differently at
the top level, it will try to enable a feature with the exact name
"bar/fast", and Context::resolve_features will later find that no such
feature exists for package foo.
To give a friendlier error message, we also check in
Context::resolve_features that we never ever require a feature with a
slash in a name from a dependency.
Before this commit, it was possible to activate a feature in a transtive
dependency, using a Cargo.toml like the following one:
...
[features]
# this will enable feature fast in package bar, which is a
# dependency of foo
default = [ foo/bar/fast ]
This is a bug, and was never intended, and it is checked in other places
already. The behavior was possible because `build_features::add_feature`
treats the specification "foo/bar/fast" as just another feature. So when
we require the feature "foo/bar/fast", add_feature for foo will generate a
dependency on "foo" requiring that feature "bar/fast" is enabled. Then,
when resolving foo, add_feature will find that "bar/fast" is a required
feature, so it'll happily add "fast" as the required feature for the
dependency "foo".
The fix for this is to make sure that the `add_feature` function does
not treat `a/b` specifications as just another feature. Instead, it now
handles that case without recursion directly when it encounters it.
We can see how this resolves the above problem: when resolving foo,
add_feature for the required feature "bar/fast" will be called.
Because add_feature no longer treats such specifciations differently at
the top level, it will try to enable a feature with the exact name
"bar/fast", and Context::resolve_features will later find that no such
feature exists for package foo.
To give a friendlier error message, we also check in
Context::resolve_features that we never ever require a feature with a
slash in a name from a dependency.
bors [Wed, 29 Jun 2016 16:27:12 +0000 (09:27 -0700)]
Auto merge of #2809 - cardoe:config-updates, r=alexcrichton
respect configure options for paths
This change causes the installed paths of some files to respect the options passed to configure. It additionally adds another option and removes an unused option.
Doug Goldstein [Mon, 27 Jun 2016 13:46:36 +0000 (08:46 -0500)]
build: respect datadir, infodir, mandir, libdir, and sysconfdir
The configure script exposes datadir, infodir, mandir, libdir, and
sysconfdir but then they are unused so distros or users with
non-standard paths are not able to change things as would be expected by
the configure script.
Doug Goldstein [Tue, 28 Jun 2016 21:27:25 +0000 (16:27 -0500)]
build: strip CFG_PREFIX from CFG_{DATADIR,MANDIR,INFODIR,LIBDIR}
While these variables are not yet used by the Makefile, to be used
CFG_PREFIX must be stripped from them. The 'make install' rule creates
a tarball and then the install.sh script extracts it relative to the
prefix argument --prefix, which in the case of a Cargo install is
relative to CFG_PREFIX. This is why CFG_PREFIX needs to be stripped out
of CFG_DATADIR, CFG_MANDIR, CFG_INFODIR, and CFG_LIBDIR.
projects / cargo.git / log