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.
Previously the host/target requirement for packages was not correctly calculated
as dependency edges to build dependencies weren't traversed by accident.
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).
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.
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.
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.
Closes#777
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.
Closes#801
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.
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.
Closes#777
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.
Closes#801
Build scripts can immediately start building as soon as all build dependencies
are available and not need to wait for normal dependencies. This commit also
includes a number of refactorings and reorganizations to tidy up how build
scripts are processed.
One primary piece of state introduced in this commit is a shared Arc<Mutex<T>>
which contains information about the processed build scripts as compilation
continues. Compilation commands will draw information from this state and build
scripts will feed information back into this state to ensure it's up to date.
This commit adds the `links` manifest key as a string of a C library which is
being linked to. This is passed as an argument to the build command when not
overridden. The implementation of overrides will come soon!
With the recent resolve rewrite, `cargo update -p foo` would only update one
package in a git repository, even if the repository provided many packages.
Cargo does not currently support depending on the same git repository source
with different precise revisions, and this would cause errors down the line
depending on what happened.
This adds a fix to the `resolve_with_previous` method to ensure that any
non-registry sources being updated will not have any locked packages inside them
which would result in an invalid lockfile.
With the recent resolve rewrite, `cargo update -p foo` would only update one
package in a git repository, even if the repository provided many packages.
Cargo does not currently support depending on the same git repository source
with different precise revisions, and this would cause errors down the line
depending on what happened.
This adds a fix to the `resolve_with_previous` method to ensure that any
non-registry sources being updated will not have any locked packages inside them
which would result in an invalid lockfile.
