These commits add two vectors through which the compiler run can be configured:
* A `RUSTC` environment variable
* A `build.rustc` configuration variable in a `.cargo/config` file
In addition to global RUSTC/RUSTDOC env vars, this commit recognizes
`build.rustc` and `build.rustdoc` as configuration keys for Cargo to instruct
what tools should be used instead of the default.
Closes#967
Whenever Cargo infers various targets for a project it currently picks up all
files in associated folders, but dotfiles are a common example of files which
editors generate which Cargo should not pick up, so this commit ignores all
dotfiles in the folders that it is looking at.
Closes#1615
Check for existence of file in dl_path before fetching with curl.
If file exists, compare hash with expected.
Also wrap tarfile.open() in contextlib.closing() to support older
python versions (<= 2.6).
This fixes part of #1525.
Check for existence of file in dl_path before fetching with curl.
If file exists, compare hash with expected.
Also wrap tarfile.open() in contextlib.closing() to support older
python versions (<= 2.6).
This fixes part of #1525.
Not having a lifetime parameter on the ubiquitous Config structure allows a
great deal of other lifetime annotations to be removed and should make dealing
with storage of Config in a structure much easier (only one lifetime to deal
with, not two).
Whenever Cargo infers various targets for a project it currently picks up all
files in associated folders, but dotfiles are a common example of files which
editors generate which Cargo should not pick up, so this commit ignores all
dotfiles in the folders that it is looking at.
Closes#1615
Some simple validation for package/target names. Currently failure for these cases happens later in rustc (e.g. "crate name must not be empty") or at the os level (e.g. "Is a directory" error when package name is empty on linux). Better to handle this earlier so it's consistent across platforms.
Still could do with a lot of validation for invalid characters etc. though.
## 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
