bors [Thu, 7 May 2015 19:18:10 +0000 (19:18 +0000)]
Auto merge of #1568 - sondrele:rustc-subcommand, r=alexcrichton
## Work in progress
I have followed issue #595 for a while now. I hope that this PR can solve it, after it's done of course.
@alexcrichton: on IRC the other day, you suggested adding a `Vec<String>` to the `CompileOptions`. I have done this, but wasn't sure what the best way to identify the correct `Target` would be, so currently everything gets compiled with the additional arguments.
I considered adding a `Target` structure to the `CompileOptions` as well, and then in `cargo_rustc::build_base_args` only append the arguments if the `Target` matches. What do you think about this? Is there an easier way of figuring out the correct `Target`?
bors [Thu, 7 May 2015 18:39:48 +0000 (18:39 +0000)]
Auto merge of #1590 - alexcrichton:issue-1589, r=brson
Knowing the target architecture for calculating the filename is needed when
calculating the name of a dynamic library, and previously this was only taken
into account when a target was a plugin. Targets can, however, request that they
are built as a dynamic library which also needs to be taken into account.
Alex Crichton [Thu, 7 May 2015 02:29:05 +0000 (19:29 -0700)]
Add a Kind argument to target_filenames
Knowing the target architecture for calculating the filename is needed when
calculating the name of a dynamic library, and previously this was only taken
into account when a target was a plugin. Targets can, however, request that they
are built as a dynamic library which also needs to be taken into account.
bors [Tue, 5 May 2015 23:28:56 +0000 (23:28 +0000)]
Auto merge of #1584 - alexcrichton:issue-797, r=brson
Closes #797
Closes #1575
This is a reopening of #1170 but I see the two closed issues as important enough that this needs to land in some form or another, and I'm more comfortable with always taking into account untracked files than only if there isn't a commit yet.
bors [Tue, 5 May 2015 17:42:08 +0000 (17:42 +0000)]
Auto merge of #1577 - alexcrichton:issue-1567, r=brson
Previously if a package had been activated without the default feature and then
it was attempted to be reactivated with the default feature, resolution wouldn't
continue and actually activate the default feature. This means that the
fingerprint on the other end of compilation would be slightly different because
the set of activated features would be slightly different, causing spurious
recompiles.
Alex Crichton [Tue, 5 May 2015 05:55:03 +0000 (22:55 -0700)]
Check default features when skipping resolution of a package
Previously if a package had been activated without the default feature and then
it was attempted to be reactivated with the default feature, resolution wouldn't
continue and actually activate the default feature. This means that the
fingerprint on the other end of compilation would be slightly different because
the set of activated features would be slightly different, causing spurious
recompiles.
Sondre Lefsaker [Sat, 2 May 2015 23:11:46 +0000 (01:11 +0200)]
Add more tests:
- `build_with_args_to_one_of_multiple_binaries`, verify that only one bin gets built
- `fails_with_args_to_all_binaries`
- `build_with_args_to_one_of_multiple_tests`, same behavious as for the binaries
- `build_foo_with_bar_dependency`, verify that bar dependency gets built and only foo gets compiled with args
- `build_only_bar_dependency`, build the bar package, that foo depends, on with the extra args
Sondre Lefsaker [Sat, 2 May 2015 16:18:05 +0000 (18:18 +0200)]
Modify test to build `main` like before, but `lib` also gets built as a dependency.
- The test verifies that the trailing arguments only gets passed to the binary being built
Sondre Lefsaker [Sat, 2 May 2015 14:30:16 +0000 (16:30 +0200)]
Remove the arguments from `BuildConfig` and append them to the profile that's being compiled instead.
- An error will be returned if the length of `targets` is not 1
- The profile of `targets` gets cloned in order to append the extra arguments.
- The new test verifies that the build fails due to both `lib` and `main` being compiled
Sondre Lefsaker [Sat, 2 May 2015 10:59:58 +0000 (12:59 +0200)]
Add new field `rustc_args` to the `Profile`
- This field will be set by the `cargo rustc` command, only if one target is being compiled
- The field can not be read from the Cargo.toml
Sondre Lefsaker [Fri, 1 May 2015 23:01:30 +0000 (01:01 +0200)]
Pass the `arg_opts` from the command line further on to the CompileOptions.
- The new tests verifies that the extra arguments gets appended to the command. One is for lib and one is for main
- Currently the arguments gets passed on to *every* target that gets built, so the tests only contain one file each
Sondre Lefsaker [Fri, 1 May 2015 21:47:07 +0000 (23:47 +0200)]
Add a new field to CompileOptions and BuildConfig: `target_rustc_args`
- The new field is a list with arguments to compile the target with.
- There should only be one target that gets compiled with these arguments
Auto merge of #1566 - alexcrichton:fix-transitive-update-dash-p, r=brson
Currently when a dependency is transitively updated the source may not itself be
updated, so an update may not happen at all. This commit modifies this behavior
to be sure to add the non-updated source to the registry for any matching
package which will trigger the source to update itself.
Auto merge of #1564 - alexcrichton:right-timeout, r=brson
Previously a timeout was set via libcurl's blanket timeout option, which is a
timeout for the entire request. This isn't always what we want, however, as
cargo is used on quite a variety of networks. Instead what we really want is
timing out data being received, so instead of a blanket timeout we set two
different timeouts:
* The connect timeout is now configured (time it takes to connect the socket)
* A "low speed" timeout is now also set. This means that if Cargo doesn't
receive 10 bytes of data in the specified tiemout period that the entire
transfer will be timed out.
Alex Crichton [Wed, 29 Apr 2015 18:58:13 +0000 (11:58 -0700)]
Tweak the meaning of HTTP timeouts
Previously a timeout was set via libcurl's blanket timeout option, which is a
timeout for the entire request. This isn't always what we want, however, as
cargo is used on quite a variety of networks. Instead what we really want is
timing out data being received, so instead of a blanket timeout we set two
different timeouts:
* The connect timeout is now configured (time it takes to connect the socket)
* A "low speed" timeout is now also set. This means that if Cargo doesn't
receive 10 bytes of data in the specified tiemout period that the entire
transfer will be timed out.
Alex Crichton [Thu, 30 Apr 2015 01:42:52 +0000 (18:42 -0700)]
Fix transitively updating dependencies
Currently when a dependency is transitively updated the source may not itself be
updated, so an update may not happen at all. This commit modifies this behavior
to be sure to add the non-updated source to the registry for any matching
package which will trigger the source to update itself.
Auto merge of #1558 - alexcrichton:less-hashes, r=brson
The root crate often has artifacts which are later intended for distribution of
some form, so adding a hash will just make predicting the file name difficult.
The hash also isn't necessary as it's guaranteed to not conflict with other
files (no other dependencies are in the same directory) and all other libraries
have metadata so symbols will not conflict.
Auto merge of #1505 - alexcrichton:issue-1478, r=brson
This commit enables the build script for a crate to provide feedback to the
crate itself about how it should be built. This is done through the `--cfg`
flags of the compiler, and each build script is now allowed to print `rustc-cfg`
directives to inform Cargo about what `--cfg` flags it should pass.
All `--cfg` flags are local to the current crate and are not propagated outwards
to transitive dependencies. The primary use-case that this feature is targeting
is compile-time feature detection for applications like C bindings or C
libraries where the version being targeted may change over time.
Auto merge of #1557 - alexcrichton:exhaustive, r=brson
This commit fills out the functionality of `--lib`, `--test`, `--bin`,
`--bench`, and `--example` for the `cargo {test,build,bench}` commands all at
once. The support for all of this was introduced long ago, and the flags just
weren't exposed at the time.
Alex Crichton [Wed, 29 Apr 2015 18:30:20 +0000 (11:30 -0700)]
Relax the test for ar/linker with plugins
On windows it won't actually succeed or get past the first compile with cc/ar,
so just set it to something that for sure won't exist so it doesn't progress on
*any* platform.
Alex Crichton [Wed, 29 Apr 2015 17:12:23 +0000 (10:12 -0700)]
Don't put hashes in libraries of the root crate
The root crate often has artifacts which are later intended for distribution of
some form, so adding a hash will just make predicting the file name difficult.
The hash also isn't necessary as it's guaranteed to not conflict with other
files (no other dependencies are in the same directory) and all other libraries
have metadata so symbols will not conflict.
Alex Crichton [Wed, 29 Apr 2015 16:42:29 +0000 (09:42 -0700)]
Allow more advanced filtering of what to build
This commit fills out the functionality of `--lib`, `--test`, `--bin`,
`--bench`, and `--example` for the `cargo {test,build,bench}` commands all at
once. The support for all of this was introduced long ago, and the flags just
weren't exposed at the time.
Auto merge of #1540 - lfairy:strip-affixes, r=alexcrichton
If the user invokes `cargo new` with a name of the form `rust-foo` or `foo-rs` (or any variation of the two), and the `--bin` option is *not* present, then the resulting `Cargo.toml` will have a `name` field of just `foo` instead.
Auto merge of #1535 - mohtar:doc-open, r=alexcrichton
`start` is not an actual executable, but rather a built-in command in Command Prompt. The correct way of launching a file using the default application is thus: `cmd /C start "" <file>`.
Since #318, the `doc` command generates documentation for binaries in addition to libraries. But currently running `cargo doc --open` would not launch the browser for binary-only packages, even though it should. This commit changes the logic: binaries will be searched when there are no libraries in the package.
A simple test case:
`Cargo.toml`:
[package]
name = "foo"
version = "0.1.0"
authors = []
Alex Crichton [Thu, 9 Apr 2015 21:35:48 +0000 (14:35 -0700)]
Allow build script feedback to the crate compiled
This commit enables the build script for a crate to provide feedback to the
crate itself about how it should be built. This is done through the `--cfg`
flags of the compiler, and each build script is now allowed to print `rustc-cfg`
directives to inform Cargo about what `--cfg` flags it should pass.
All `--cfg` flags are local to the current crate and are not propagated outwards
to transitive dependencies. The primary use-case that this feature is targeting
is compile-time feature detection for applications like C bindings or C
libraries where the version being targeted may change over time.
Auto merge of #1519 - alfiedotwtf:master, r=alexcrichton
Currently getting:
note: /usr/bin/ld: /home/alfie/tmp/test/target/debug/build/test-39af07f97c17512a/out/libhello.a(hello.o):
relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
Alfie John [Mon, 13 Apr 2015 12:36:32 +0000 (22:36 +1000)]
docs: fix shared library compilation error
Currently getting:
note: /usr/bin/ld: /home/alfie/tmp/test/target/debug/build/test-39af07f97c17512a/out/libhello.a(hello.o):
relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
Auto merge of #1507 - jimmycuadra:cargo-new-semver, r=alexcrichton
This patch updates the initial version of packages generated with `cargo new` to 0.1.0 (rather than 0.0.1), which better follows SemVer. The docs are also updated to show examples that follow this convention.
For reference, the same change was recently made in Bundler for the Ruby ecosystem: bundler/bundler#3322