bors [Mon, 17 Nov 2014 18:44:30 +0000 (18:44 +0000)]
auto merge of #896 : jgillich/cargo/patch-3, r=alexcrichton
Currently the command output looks like this on Fedora:
```
$ curl https://static.rust-lang.org/rustup.sh | sudo bash
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 9866 100 9866 0 0 39592 0 --:--:-- --:--:-- --:--:-- 39622[sudo] password for jakob:
```
The first time I ran it, I didn't even realize it is asking for a password. By using the options for `silent` and `show-error`, we get this:
```
$ curl -sS https://static.rust-lang.org/rustup.sh | sudo bash
[sudo] password for jakob:
```
And errors are still displayed:
```
$ curl -sS https://example.invalid | sudo bash
curl: (6) Could not resolve host: example.invalid
[sudo] password for jakob:
```
bors [Fri, 14 Nov 2014 23:33:33 +0000 (23:33 +0000)]
auto merge of #865 : alexcrichton/cargo/no-more-name, r=brson
With #843 and #839 coming around the bend soon, the original decision for
`--name` everywhere isn't making as much sense, for consistence this is renaming
these flags back to `--<target-name>` for the respective targets.
bors [Fri, 14 Nov 2014 22:44:28 +0000 (22:44 +0000)]
auto merge of #861 : alexcrichton/cargo/issue-800, r=brson
This commit is an architectural change inside of Cargo itself in the way that it
handles the output format of builds. Previously when a build start, all existing
directories and files would be renamed to `old-foo` folders. The build would
then `rename` all files back into the right location as they were seen as fresh
and needed for the build.
The benefit of a system such as this is a rock-solid guarantee that the build
tree contains exactly what it would if we were to start the build from a totally
clean directory each time. There are some downsides, however:
* In #800, it was discovered that this method has an unfortunate interaction
with Docker. Docker apparently will mount many filesystems which `rename` will
not work across.
* I have seen countless flaky failures on windows due to an attempt to remove a
file that was still in use somehow. I've never been able to truly track down
why these failures are happening, however.
The new system for managing output files is to build up a list of all known
files at the start of a build, whitelist any necessary files when the build is
being prepared, and then wipe out all unknown files right before the build
begins. This is not quite as close to the guarantee as the benefits reaped
before because on the second build all build files will still be in their final
output locations, they may just get updated as part of the build as well. This
seems like an acceptable compromise, however.
Alex Crichton [Thu, 13 Nov 2014 05:35:33 +0000 (21:35 -0800)]
Stop shuffling output files around so often
This commit is an architectural change inside of Cargo itself in the way that it
handles the output format of builds. Previously when a build start, all existing
directories and files would be renamed to `old-foo` folders. The build would
then `rename` all files back into the right location as they were seen as fresh
and needed for the build.
The benefit of a system such as this is a rock-solid guarantee that the build
tree contains exactly what it would if we were to start the build from a totally
clean directory each time. There are some downsides, however:
* In #800, it was discovered that this method has an unfortunate interaction
with Docker. Docker apparently will mount many filesystems which `rename` will
not work across.
* I have seen countless flaky failures on windows due to an attempt to remove a
file that was still in use somehow. I've never been able to truly track down
why these failures are happening, however.
The new system for managing output files is to build up a list of all known
files at the start of a build, whitelist any necessary files when the build is
being prepared, and then wipe out all unknown files right before the build
begins. This is not quite as close to the guarantee as the benefits reaped
before because on the second build all build files will still be in their final
output locations, they may just get updated as part of the build as well. This
seems like an acceptable compromise, however.
bors [Fri, 14 Nov 2014 17:14:33 +0000 (17:14 +0000)]
auto merge of #868 : IanConnolly/cargo/backtick_fix, r=alexcrichton
19:09 < ianconnolly> hey, i was browsing the cargo code, any particular reason why this string is mixed backticks + straight apostrophes?
https://github.com/rust-lang/cargo/blob/master/src/bin/cargo.rs#L157
19:10 < acrichto> ianconnolly: oh I think I missed that, it should probably just be `{}` like the rest of cargo
bors [Fri, 14 Nov 2014 01:29:40 +0000 (01:29 +0000)]
auto merge of #845 : jbranchaud/cargo/add-missing-semicolon-for-new-project-main, r=alexcrichton
When you run `cargo new project-name --bin`, a project is generated by cargo
with a file, `src/main.rs`. This file has a main function with one line that
prints hello, world, but a semicolon is missing from the end of the
expression.
bors [Thu, 13 Nov 2014 22:45:53 +0000 (22:45 +0000)]
auto merge of #864 : tomaka/cargo/fix-814, r=alexcrichton
Close #814
Unfortunately I don't really know how I'd add a test for this.
In order to try compile a library then a binary, you need to successfully compile the library, which means that you'd need to pass a valid value instead of just `-l foo`
bors [Thu, 13 Nov 2014 19:23:05 +0000 (19:23 +0000)]
auto merge of #842 : alexcrichton/cargo/issue-838, r=brson
A package can be required to be built for both the host and target architectures
in some cases. For example a crate could be a normal dependency and a build
dependency. Cargo specially handles this case with respect to the build script
to ensure that the build script is run once per output platform.
Cargo also has logic, however, to run the build script only once when the target
and host platforms are the same. In this case Cargo previously wasn't filling in
the local build script output cache for both the host and target platforms, just
the target platform. This commit remedies this situation by ensuring that cargo
populates both the host and target locations in the cache.
bors [Thu, 13 Nov 2014 19:07:46 +0000 (19:07 +0000)]
auto merge of #859 : alexcrichton/cargo/issue-856, r=alexcrichton
I don't really expect all builders of cargo to be forced to use this rustc, and
I expect this to update frequently, but it will allow cargo PRs to land without
forcing a "put out the fires" fix for all nightly incompatibilities all at once.
This will allow rust upgrades to land separately and be reviewed separately.
Alex Crichton [Thu, 13 Nov 2014 00:05:33 +0000 (16:05 -0800)]
Pin rustc to a date with known snapshots
I don't really expect all builders of cargo to be forced to use this rustc, and
I expect this to update frequently, but it will allow cargo PRs to land without
forcing a "put out the fires" fix for all nightly incompatibilities all at once.
This will allow rust upgrades to land separately and be reviewed separately.
Alex Crichton [Thu, 13 Nov 2014 17:37:09 +0000 (09:37 -0800)]
Rename --name flags to --<target-name>
With #843 and #839 coming around the bend soon, the original decision for
`--name` everywhere isn't making as much sense, for consistence this is renaming
these flags back to `--<target-name>` for the respective targets.
bors [Thu, 13 Nov 2014 03:29:37 +0000 (03:29 +0000)]
auto merge of #844 : alexcrichton/cargo/less-registry, r=brson
Try to purge the word "registry" as much as possible in favor of just referring
to crates.io as "crates.io". This also enables the default index as being the
official rust-lang crates.io index.
Alex Crichton [Tue, 11 Nov 2014 19:59:31 +0000 (11:59 -0800)]
Fix a panic when building with build scripts
A package can be required to be built for both the host and target architectures
in some cases. For example a crate could be a normal dependency and a build
dependency. Cargo specially handles this case with respect to the build script
to ensure that the build script is run once per output platform.
Cargo also has logic, however, to run the build script only once when the target
and host platforms are the same. In this case Cargo previously wasn't filling in
the local build script output cache for both the host and target platforms, just
the target platform. This commit remedies this situation by ensuring that cargo
populates both the host and target locations in the cache.
jbranchaud [Wed, 12 Nov 2014 05:00:05 +0000 (23:00 -0600)]
Add the semicolon missing from the generated main.rs contents.
When you run `cargo new project-name --bin`, a project is generated by cargo
with a file, `src/main.rs`. This file has a main function with one line that
prints hello, world, but a semicolon is missing from the end of the
expression.
bors [Tue, 11 Nov 2014 22:44:53 +0000 (22:44 +0000)]
auto merge of #817 : alexcrichton/cargo/build-cmd, r=brson
This registers a new cargo snapshot as well as updates all dependencies to versions that are using build scripts. This means that overrides can now be used when looking for native libs for cargo!
This also modifies the behavior of `--enable-nightly` to add some extra configuration the buildbot needs to build cargo on CentOS.
Alex Crichton [Tue, 11 Nov 2014 20:24:50 +0000 (12:24 -0800)]
Update the UI around using crates.io
Try to purge the word "registry" as much as possible in favor of just referring
to crates.io as "crates.io". This also enables the default index as being the
official rust-lang crates.io index.
Alex Crichton [Mon, 10 Nov 2014 17:52:14 +0000 (09:52 -0800)]
Cache build output in the target build directory
Placing it in the host directory may end up later on down the road causing a
spurious recompilation when one isn't necessary. I couldn't currently think of a
test case for this, as I don't think that this affects correctness.
bors [Fri, 7 Nov 2014 21:15:52 +0000 (21:15 +0000)]
auto merge of #815 : alexcrichton/cargo/another-fix-oh-by-wait-i-verified-this-one-its-ok, r=alexcrichton
Previously the host/target requirement for packages was not correctly calculated
as dependency edges to build dependencies weren't traversed by accident.
Alex Crichton [Fri, 7 Nov 2014 20:59:44 +0000 (12:59 -0800)]
Another fix for cross-compiled build scripts
Previously the host/target requirement for packages was not correctly calculated
as dependency edges to build dependencies weren't traversed by accident.
bors [Fri, 7 Nov 2014 19:28:57 +0000 (19:28 +0000)]
auto merge of #813 : alexcrichton/cargo/build-cmd-cross-compile, r=brson
These commits contain a number of improvements to the usage of build scripts when cross compiling. A few erroneous assumptions were made to start out with, and this also fixes the long-standing bug of using build scripts in host packages (e.g. plugins and build dependencies).
Alex Crichton [Fri, 7 Nov 2014 19:09:59 +0000 (11:09 -0800)]
Fix build scripts and double-compiled packages
This commit fixes support for build scripts in packages which are compiled for
both the host and target architectures. The support was previously hindered by
the fact that the build script was always invoked precisely once for the target
architecture unconditionally.
This adds support for build scripts themselves to depend on build scripts, and
everything should "just work" if build scripts respect their environment
variables.
Alex Crichton [Fri, 7 Nov 2014 17:25:25 +0000 (09:25 -0800)]
Fix cross compiling with a build script
Previously there was a mixup of where the build script was getting compiled into
as well as where the output was going to. This commit fixes the problems for
now, but still has room for improvement in the future.
Build scripts themselves are now unconditionally built into `target/build/..`
because they're compiled for the host platform. Their outputs are in
`target/$target/build/..` as expected.
bors [Fri, 7 Nov 2014 16:52:47 +0000 (16:52 +0000)]
auto merge of #798 : alexcrichton/cargo/issue-777, r=brson
At the same time this commit renames the `.tar.gz` extension to `.crate`. This
helps our perception on Windows as we're not trying to leave them out in the
dark, and we'd also like the ability to modify the format later in the future.
bors [Thu, 6 Nov 2014 00:02:30 +0000 (00:02 +0000)]
auto merge of #799 : alexcrichton/cargo/moar-parallel, r=brson
When building unit tests for a library, we don't need the library itself to be
built beforehand, so the two can be built in parallel. If the crate takes awhile
to compile, this shows some excellent wall-time speedups.
bors [Wed, 5 Nov 2014 23:02:41 +0000 (23:02 +0000)]
auto merge of #802 : alexcrichton/cargo/issue-801, r=brson
Previously all features were traversed when adding information to the lockfile,
but the traversal forgot to add optional dependencies that did not have a
corresponding feature.
bors [Wed, 5 Nov 2014 22:35:35 +0000 (22:35 +0000)]
auto merge of #803 : alexcrichton/cargo/fix-some-tests, r=alexcrichton
Right now we're accidentally not actually leveraging this function well in some
tests due to this sequence of events:
1. The tests run at time X, building artifacts that remember the fingerprint is
at time X.
2. The entire project is moved back one hour to (X-1).
3. A new file is created, at time X (second-level resolution on some systems).
4. On a rebuild, the maximum mtime is still X (due to the new file).
For this reason there are some more calls to move_into_the_past() to push files
back another hour after they've been created to make sure the maximum mtime is
(X-1), or something different than X.
Alex Crichton [Wed, 5 Nov 2014 22:00:38 +0000 (14:00 -0800)]
More aggresively move_into_the_past for tests
Right now we're accidentally not actually leveraging this function well in some
tests due to this sequence of events:
1. The tests run at time X, building artifacts that remember the fingerprint is
at time X.
2. The entire project is moved back one hour to (X-1).
3. A new file is created, at time X (second-level resolution on some systems).
4. On a rebuild, the maximum mtime is still X (due to the new file).
For this reason there are some more calls to move_into_the_past() to push files
back another hour after they've been created to make sure the maximum mtime is
(X-1), or something different than X.
Alex Crichton [Wed, 5 Nov 2014 03:40:06 +0000 (19:40 -0800)]
Build lib tests and libraries in parallel
When building unit tests for a library, we don't need the library itself to be
built beforehand, so the two can be built in parallel. If the crate takes awhile
to compile, this shows some excellent wall-time speedups.
bors [Wed, 5 Nov 2014 21:13:08 +0000 (21:13 +0000)]
auto merge of #792 : alexcrichton/cargo/build-cmd, r=brson
This series of commits (based on https://github.com/rust-lang/cargo/pull/763) is an implementation of the recent [Cargo RFC](https://github.com/rust-lang/rfcs/blob/master/text/0403-cargo-build-command.md). This should implement all portions of the RFC, but there's a lot so an extra set of eyes would be nice!
I haven't added documentation for it all yet, but I would like to do so before landing (starting with https://github.com/rust-lang/cargo/pull/749). Otherwise I've been migrating all of the existing cargo dependencies away from the build command to a build script, and the progress can be seen with these repositories: