## 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`?
r? @alexcrichton
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.
Closes#1589
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.
Closes#1589
Closes#797Closes#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.
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.
Closes#1567
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.
Closes#1567
- `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
- 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
- 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
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.
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.
Closes#1560
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.
Closes#1560
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.
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.
Closes#1484
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.
Closes#1478
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.
