This command is used to download all dependencies of a package ahead of time to
ensure that no more network communication will be necessary as part of a build.
cc #358
The CLI has started to have differences on windows than on other systems, and
instead of coding against multiple CLI versions, instead just rewrite everything
to use libgit2.
Travis is showing intermittent failures in
`test_cargo_compile_path_deps::path_dep_build_cmd` and
`test_cargo_compile_git_deps::git_dep_build_cmd` (added in #561 and #563).
I haven't managed to reproduce these failures locally, but I suspect the tests
are timing-sensitive. This tries to guarantee that the timestamps during the
two operations can't be the same.
`list_files_git` assumes that the package is at the root of the git repository. This breaks when trying to list files for a package in a subdirectory of a repo, or in other cases, e.g. if the user's home directory is a git repo.
When cloning a remote repository, the default behavior of libgit2 is to only
update the local ref that's actually checked out, when we actually would prefer
to update all refs of the remote repo. This removes a call to clone() to a
init_bare() + fetch() which should update all refs accordingly
Closes#565
This primarily blows away all *submodules* as well, which sometimes can be quite
large and take some time to update. Instead, re-use an existing checkout, just
reset it to the right revision if possible.
Also, move the submodule update step to occur unconditionally to account for
corrupt submodule checkouts or interrupted downloads. This update step should be
much faster than `git submodule update` because we're using libgit2, so yay!
This primarily blows away all *submodules* as well, which sometimes can be quite
large and take some time to update. Instead, re-use an existing checkout, just
reset it to the right revision if possible.
Also, move the submodule update step to occur unconditionally to account for
corrupt submodule checkouts or interrupted downloads. This update step should be
much faster than `git submodule update` because we're using libgit2, so yay!
The previous logic for recompiling any dependency was almost entirely based on
the mtimes of the relevant input files. This isn't quite what's desired for git
and registry dependencies because the mtime could be fluctuating while the files
aren't changing. For example:
1. Project A checks out git repo C at revision C1
2. Project A builds, records mtimes of C
3. Project B checks out git repo C at revision C2
4. Project B builds, records new mtimes of C
5. Project A is rebuilt, rebuilding C b/c mtimes are different
In step 5 here C should not be rebuilt because the revision didn't actually
change.
This commit alters git/registry dependencies to completely bypass the --dep-info
emitted and only rely on the git/registry source to inform what the fingerprint
is. This is the revision/version, respectively, and should be all that's
necessary to track changes to the repo and trigger a rebuild.
It turned out most of the methods in libgit2 don't actually require a Signature
structure, they're all mostly optional. This commit updates to this version of
libgit2 where the arguments are all optional.
This commit removes all distributed executables except for `cargo`. All
builtin subcommands are implemented through library calls, and the fallback
methods are retained to maintain extensability through new subcommands.
Closes#393
Previously, the Git code avoided cloning a local copy of the local
database for a repository if the repo already existed (and instead tried
to fetch). However, fetching does not sync and reinitialize submodules,
which would require more work.
To avoid this problem, and possibly other subtle updating issues in the
future, the code now wipes the local clone whenever it detects that the
HEAD of a particular branch has changed. This avoids subtle
inconsistencies between fresh clones and updates.
Note: This only affects local-to-local clones. It does not initiate any
new network activity. It may require some additional disk usage, but
only when a remote fetch that was already happening discovers new
commits on the checked-out branch.
Previously `cargo update foo` would only update the package `foo` if it were a
direct dependency of the local package. This meant that to update a transitive
dependency you would have to update the top-level dependency.
This commit adds the ability to update any dependency by name, regardless of
where it is in the dependency graph. This commit is a bit lossy in terms of
behavior. We are guaranteed that the set of immediate dependencies for any one
package have unique names, but not for the entire package graph. This means that
when you invoke `cargo update foo` it could possibly update two packages named
`foo`.
I believe this behavior to be acceptable for now and we can add a more stringent
update syntax later (something like `cargo update --namespace foo bar`). I
believe we'll always want this CLI usage, however.
When testing the freshness of a build command, the fingerprint of an entire
package is generated. The current method of fingerprinting a path source is to
just stat() the entire tree and look at mtimes. This works fine when the build
command places *all* output in the build directory.
Some systems, like autotools, place *most* output in the build directory and
some output in the source directory, however (see spidermonkey). In this case
the coarse-grained "consider all files in a directory as input" is too painful
for the build command as the package will forever be rebuilt.
This commit adds support for filtering the list of files in a directory
considered to be part of a package by using `git ls-files`. This git-specific
logic can be extended to other VCSs when cargo grows support for them.
Closes#379
This commit changes the hash of Profile to only take into account
flags/variables that affect the actual output file itself (as opposed to its
location), and then changes cargo {test, build, doc} to all use the same
directory of output (in order to share deps).
This will cause a `cargo build` to remove all of the tests generated by `cargo
test`, but it speeds up the cycle of `cargo test` followed by a `cargo build` by
not needing to rebuild all dependencies.
Additionally, `cargo bench` now shares the same directory as
`cargo build --release` for the same reasons as above.
Closes#348
Previously an invocation of `cargo build` would generate a lockfile *without*
dev dependencies, but an invocation of `cargo test` would generate a lockfile
*with* dependencies. This causes odd problems and diffs with the lockfile.
This commit switches the resolve-to-be-a-lockfile to using all dependencies of a
package, while the resolve-to-be-compiled continues to use just the dependencies
needed for the current build.
The syntax was originally chosen to perhaps allow multiple libraries in the future, but that is less and less likely to happen at this point. This commit deprecates the now-misleading `[[lib]]` in favor of `[lib]` to indicate that only one can be present.
This does not start allowing `[bin]` or `[example]` and such as I felt that it was too many ways to specify what's essentially the same thing. This also as a bonus allows a top-level `bin = []` to completely opt-out of binary inference (as well as for tests and examples).
Closes#327
We observed that after updating the git repo in a test, unless we waited
for 1s, we got intermittent cases where a subsequent update of the git
source would not pick up the changes.
We observed this both with the git CLI and the branch using libgit2.
There may be a better solution, but we did not find it.
I customized my git repo template to default to the standard pre-commit
hook that checks for e.g. trailing whitespace and refuses to commit if
any trailing whitespace was found. This causes some of cargo's tests to
fail.
To be independent of the user's git template, create the repo for the
test without using any, by specifying an empty template.
The fingerprinting code was erroneously using all sources from a manifest when
calculating the fingerprint which meant that sources not yet downloaded were
attempted to be fingerprinted.
The correct source to fingerprint is located in the SourceId field of the
resolved PackageId.
Closes#259
This ends up serving the same purpose, but a critical change is that it
canonicalizes the relevant git url (if one is used) to ensure that the same
package from two slightly different locations is always built the same way.
Sadly I'm not quite sure how to add a test for this as it involves using remote
git urls which are unusable during tests.
TOML recently grew multiline string literals as well as literal strings with no
escaping, which can be used instead of the hokey escape_path() function.
This allows the dependency queue to properly handle packages with the same
name but from different sources.
A test was added which exercieses this functionality by depending on two
different revs of the same git repo.
