Matt Brubeck [Thu, 11 Sep 2014 19:00:11 +0000 (12:00 -0700)]
Fix bug in list_file_walk when cwd != path
Previously this was calling .is_file() on a relative path. This would fail if
the path was not relative to the current working directory, for example when
fingerprinting a path dependency.
auto merge of #559 : mbrubeck/cargo/make-install-fix, r=alexcrichton
This fixes an issue where `make dist` incorrectly does nothing after the source has changed and been rebuilt. It also prevents `make install` from installing outdated files from the `dist` directory.
Brian Koropoff [Thu, 11 Sep 2014 05:29:14 +0000 (22:29 -0700)]
Fix build break by upgrading git2-rs
Update git2-rs to the latest version which includes a fix for `extern crate`
syntax changes. This version changes the interface for credential callbacks,
so update the git source provider code as well.
auto merge of #550 : alexcrichton/cargo/rustdoc, r=brson
* All markdown files are now rendered with `rustdoc` into HTML
* A JS syntax highlighter, prism, is included for TOML syntax highlighting.
* A new makefile target, `make doc`, will build docs into `target/doc`
Alex Crichton [Sun, 7 Sep 2014 17:53:20 +0000 (10:53 -0700)]
Move to rustdoc instead of ruby's middleman
* All markdown files are now rendered with `rustdoc` into HTML
* A JS syntax highlighter, prism, is included for TOML syntax highlighting.
* A new makefile target, `make doc`, will build docs into `target/doc`
auto merge of #549 : alexcrichton/cargo/git-no-delete, r=brson
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!
auto merge of #548 : alexcrichton/cargo/frobbing-git-deps, r=brson
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.
Alex Crichton [Wed, 10 Sep 2014 14:47:11 +0000 (07:47 -0700)]
Don't blow away checked out git repos
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!
Alex Crichton [Wed, 10 Sep 2014 14:26:42 +0000 (07:26 -0700)]
Don't recompile git deps so frequently
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.
auto merge of #513 : bkoropoff/cargo/revert-static, r=alexcrichton
This reverts a commit that worked around an overly restrictive lifetime bound on the `Writer` impl for `Box<Writer>` in libstd. Now that this restriction has been lifted, the workaround can be reverted.
Alex Crichton [Sun, 7 Sep 2014 18:26:07 +0000 (11:26 -0700)]
Don't run cargo as root during `make install`
This rejiggers the dependencies for `make install` to only copy files into the
destination, never assemble anything. This adds a hard requirement that `make`
is executed before `make install`.
auto merge of #503 : alexcrichton/cargo/issue-493, r=brson
This commit updates git2-rs to get the implementation of the authentication
callback in libgit2. Additionally this specifies the callback for whenever we're
cloning into the database or updating submodules.
Currently cargo will *not* ask for user input, but rather require you to have
authentication configured in git through some other means. There are currently
two primary methods of doing so:
1. Any SSH key in the local ssh-agent will be used for authentication with SSH
repositories.
2. The `credential.helper` interface (as specified by gitcredential(7)) has been
implemented in git2-rs to allow for picking up of storage of passwords in the
local git cache or keychain.
If these two methods fail, then there will likely be an authentication failure.
Interactive prompts for authentication have not been implemented as there is no
method to currently enter your password into the terminal silently.
A consequence of this commit is that cargo now depends on libssh2. A package was
created to create a static copy of libssh2, and this is now linked into cargo by
default.
It turned out that just building libssh2 was quite a beast in and of itself on
windows. The primary stickler point is that on the current release, 1.4.3,
libssh2 requires openssl on windows. At this time I don't want to pick up a
dependency on openssl for windows, and it turned out that the unreleased 1.4.4
version has a new backend for windows not based on openssl, but rather windows's
cryptography API.
The current bundled version of libssh2 is 1.4.4 with some light modifications to
actually build on windows (wow that was hard). All in all, we're now statically
linking to libssh 1.4.4 (not a runtime dependency).
Alex Crichton [Mon, 1 Sep 2014 06:03:45 +0000 (23:03 -0700)]
Implement git authentication
This commit updates git2-rs to get the implementation of the authentication
callback in libgit2. Additionally this specifies the callback for whenever we're
cloning into the database or updating submodules.
Currently cargo will *not* ask for user input, but rather require you to have
authentication configured in git through some other means. There are currently
two primary methods of doing so:
1. Any SSH key in the local ssh-agent will be used for authentication with SSH
repositories.
2. The `credential.helper` interface (as specified by gitcredential(7)) has been
implemented in git2-rs to allow for picking up of storage of passwords in the
local git cache or keychain.
If these two methods fail, then there will likely be an authentication failure.
Interactive prompts for authentication have not been implemented as there is no
method to currently enter your password into the terminal silently.
A consequence of this commit is that cargo now depends on libssh2. A package was
created to create a static copy of libssh2, and this is now linked into cargo by
default.
It turned out that just building libssh2 was quite a beast in and of itself on
windows. The primary stickler point is that on the current release, 1.4.3,
libssh2 requires openssl on windows. At this time I don't want to pick up a
dependency on openssl for windows, and it turned out that the unreleased 1.4.4
version has a new backend for windows not based on openssl, but rather windows's
cryptography API.
The current bundled version of libssh2 is 1.4.4 with some light modifications to
actually build on windows (wow that was hard). All in all, we're now statically
linking to libssh 1.4.4 (not a runtime dependency).
auto merge of #470 : alexcrichton/cargo/cargo-new-git, r=brson
This adds a command-line --no-git option to disable this behavior, as well as
adding a global config section for `git = false`. While I was at it I write some
documentation for the configuration format that cargo uses.
Alex Crichton [Thu, 28 Aug 2014 20:22:36 +0000 (13:22 -0700)]
Turn --git on by default for `cargo-new`.
This adds a command-line --no-git option to disable this behavior, as well as
adding a global config section for `git = false`. While I was at it I write some
documentation for the configuration format that cargo uses.
Alex Crichton [Wed, 3 Sep 2014 18:54:47 +0000 (11:54 -0700)]
Re-enable passing -g to rustc
Now that there is a way to disable debuginfo for a build, we can go back to
passing it by default. Any bugs in debuginfo will get weeded out by specifying
`debug = false` in the profile.
auto merge of #506 : alexcrichton/cargo/sooner-lockfile, r=wycats
It's quite annoying if you update a dependency, but it takes you awhile to get
the dependency building. Previously the dependency graph would have to be
updated each time because the lockfile was only written *after* a successful
build.
Other tools like `cargo generate-lockfile` will already generate a lockfile at
any time, so just make it easier by moving it up in the compilation process.
Alex Crichton [Wed, 3 Sep 2014 15:23:59 +0000 (08:23 -0700)]
Generate a lockfile sooner in `cargo build`
It's quite annoying if you update a dependency, but it takes you awhile to get
the dependency building. Previously the dependency graph would have to be
updated each time because the lockfile was only written *after* a successful
build.
Other tools like `cargo generate-lockfile` will already generate a lockfile at
any time, so just make it easier by moving it up in the compilation process.
auto merge of #500 : alexcrichton/cargo/fix-flaky-test, r=brson
This test has been flaky on the bots for quite some time now, and the cause has
now been discovered. The root cause of the failure is that the execve for the
`cargo --list` command was failing with ETXTBUSY. In querying the manpage, this
means:
Executable was open for writing by one or more processes.
This error can be explained by the following trace:
1. Thread A, running the `cargo --list` test, opens the destination executable
for writing because it's copying the current executable into a different
location.
2. Thread B, some other test, forks the process. The file descriptor of the
destination executable of thread A is now duplicated in this process.
3. Thread A closes all files and such, and then goes to fork/exec
`cargo --list`.
4. Thread B has not had time to close all its descriptors. so it still has the
executable open for writing, causing the `execve` of thread A to fail.
This commit just removes these tested portions of the test, only testing that
cargo probes PATH.
auto merge of #475 : alexcrichton/cargo/issue-458, r=brson
Relative paths are now considered relative to the directory containing the
`.cargo/config` file specifying the relative path.
I also merge ConfigValueValue into ConfigValue by moving the Path directly next
to the String that defined it so we can track which strings came from which
paths.
Alex Crichton [Fri, 29 Aug 2014 04:38:35 +0000 (21:38 -0700)]
Fix relative override paths
Relative paths are now considered relative to the directory containing the
`.cargo/config` file specifying the relative path.
I also merge ConfigValueValue into ConfigValue by moving the Path directly next
to the String that defined it so we can track which strings came from which
paths.
Alex Crichton [Tue, 2 Sep 2014 16:51:48 +0000 (09:51 -0700)]
Slim down the `cargo --list` test
This test has been flaky on the bots for quite some time now, and the cause has
now been discovered. The root cause of the failure is that the execve for the
`cargo --list` command was failing with ETXTBUSY. In querying the manpage, this
means:
Executable was open for writing by one or more processes.
This error can be explained by the following trace:
1. Thread A, running the `cargo --list` test, opens the destination executable
for writing because it's copying the current executable into a different
location.
2. Thread B, some other test, forks the process. The file descriptor of the
destination executable of thread A is now duplicated in this process.
3. Thread A closes all files and such, and then goes to fork/exec
`cargo --list`.
4. Thread B has not had time to close all its descriptors. so it still has the
executable open for writing, causing the `execve` of thread A to fail.
This commit just removes these tested portions of the test, only testing that
cargo probes PATH.
projects / cargo.git / log