This adds a new .cargo/config option which allows configuring the ar and linker
tools that rustc invokes. This should aid in any cross-compilation attempts.
This updates the `make install` target and adds a new `make dist` target which
will prepare a distributable tarball with an install script. All work is based
off the equivalent rust nightly tarball and nightly installation scripts.
Closes#159Closes#184
This updates the `make install` target and adds a new `make dist` target which
will prepare a distributable tarball with an install script. All work is based
off the equivalent rust nightly tarball and nightly installation scripts.
Closes#159Closes#184
I was chasing the `cargo clean` command it's way down to get a better understanding of the inner workings of cargo. Those minor documentation changes and variable renaming are the outcome which I think make the code base just a tiny bit more welcoming :)
It's not unreasonable to have unittests in a separate submodule of the
crate (being called `test` or `tests`), and having them in their own
file can be very sensible. Thus, the `src/test.rs` implicit default is
likely to trip up some perfectly reasonable use-cases. There's already
the `tests/...` default, so repairing a codebase after this removal is
just moving `src/test.rs` to `tests/whatever_name_you_want.rs`.
Closes#187.
It's not unreasonable to have unittests in a separate submodule of the
crate (being called `test` or `tests`), and having them in their own
file can be very sensible. Thus, the `src/test.rs` implicit default is
likely to trip up some perfectly reasonable use-cases. There's already
the `tests/...` default, so repairing a codebase after this removal is
just moving `src/test.rs` to `tests/whatever_name_you_want.rs`.
Closes#187.
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.
This add support for `examples/*.rs` being built (as normal bin crates) during `cargo test`,
and `src/test.rs` and `tests/*.rs` being built and run (as test crates) during `cargo test`.
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.
There are other unnamed commands like `verify-project` but I'm unsure if they are **not** listed on purpose because they should be used directly by the user less frequently. However, the clean command seems like a command that should be listed here.
Not sure about the wording though. It could be more abstract like *remove build artifacts* but given it's current behavior I think *remove target directory* is somehow straight forward, too.
This commit implements full support for plugins by answering the question of
whether any target needed as a plugin or needed as a target dependency. This
commit builds on the previous abstractions to enable parallel compilation
wherever possible.
With cross compilation soon on the horizon, it may be required to build a
library for both the host and target architectures. These two copies can
certainly be built in parallel. Additionally, all binaries produced by a package
can also be built in parallel, but are currently forced to be built
sequentially.
This commit improves this parallelism by allowing each job to create more work
before the package is considered built. Only after all targets have been built
is the new fingerprint written.