Fixes#41.
The template is adjusted to use the new macro. This will only work
if the macro is defined, thus the required version of rust-packaging
is bumped.
This is mainly targeted to the crates using `rust-cc`, where we want to
apply system-wide compiler flags when invoking the compiler. `cc`
supports CFLAGS and CXXFLAGS, but we never set those.
Defining that per project is not possible, as we have no way to inherit
any build context from a dependency package.
Possibly also affects: `bindgen`, `cxx`, any other crate that invokes
the C/C++ compiler and passes the CFLAGSS
This commit add basic support for crate vendoring in Rust. The user will
use something like `cargo vendor` to create a vendor directory (that can
later be deployed as a tgz) that contains all the dependencies.
This patch will analyze the output of `cargo manifest` to calculate the
closure of dependencies, and via the new parameter `--provides-vendor`,
print all the 'bundled(crate(NAME/FEATURE)) = 0.0.0' provided by the
binary.
The algorithm is not perfect, as today it will include all the features
resolved for the crate (not all the availables, tho), but basically is
something like:
1.- A dependency generator macro, cargo_bundled, will call
cargo-inspector like this:
# In STDIN we will provide the name of the binary
cargo-inspector --provides-vendor --path %{_builddir}
2.- cargo-inspector will search inside the 'path' tree a Cargo.toml that
generate the binary name send via STDIN.
3.- From this point, we go up to the tree to find the top-most
Cargo.toml, as this will be the directory where .cargo/config is living.
We make this directory our `cwd`.
4.- Using the metadata from `cargo manifest`, we generate the closure of
dependencies required by this binary. To simplify the problem, the
current code do not resolve the features, and accept the one resolved by
cargo as valid. Most of the time this will be OK, maybe will include
some extra features needed for other binaries.
5.- Print the 'bundled()' data.
This code will only be executed in the directory 'vendor' is present in
the top-most directory found on step 3.
If a crate has a feature with `+` in it's name,
the `%__cargo_feature_from_name` macro fails to correctly parse it.
For example, the `cxxbridge-flags` crate declares (among others)
the `c++20` feature; that is currently parsed as follows:
```lua
> string.match("cxxbridge-flags+c++20-devel", "^.+%+(.+)-devel$")
20
```
The adjusted regex matches the *first* `+` as feature name separator:
```lua
> string.match("cxxbridge-flags+c++20-devel", "^[^+]+%+(.+)-devel$")
c++20
```
+ /usr/bin/env CARGO_HOME=.cargo RUSTC_BOOTSTRAP=1 /opt/rust/bin/cargo package -l
+ grep -w -v Cargo.lock
+ xargs -d '\n' /bin/cp --parents -a -t /user/rpmbuild/BUILDROOT/rust-term_size-0.3.0-1.i2n.x86_64/datastore/dev/rust/cargo/registry/term_size-0.3.0
warning: No (git) VCS found for `/datastore/rpmbuild/BUILD/term_size-0.3.0`
/bin/cp: cannot stat 'Cargo.toml.orig': No such file or directory
Signed-off-by: Igor Raits <ignatenkobrain@fedoraproject.org>
In cargo 1.41, `cargo install` adds a new `.crates2.json` file in the
install root for tracking version upgrades. This would be another file
that `%cargo_install` should remove afterward, but there is also a new
`--no-track` option which disables such metadata files altogether.
This update should be coordinated with the Rust toolchain update in the
distro, e.g. with rust-packaging `Requires: cargo >= 1.41`. The new
option will be rejected as an unstable option on earlier versions.
It is simply impossible to fight against people putting
#![deny(warnings)] into the code…
Closes: https://pagure.io/fedora-rust/rust2rpm/issue/98
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
We need to have an easy way how to skip doing 'cargo build' to speedup a
module builds.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
This has good impact on performance and binary size at cost of
compilation time. As nice side effect, it fixes bug which breaks
compilation of binaries in Fedora Rawhide.
For example, ffsend binary went from 107M to 70M.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1701339
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
When building matrixmultiply v0.2.2:
BUILDSTDERR: /usr/bin/cp: cannot stat 'spare': No such file or directory
BUILDSTDERR: /usr/bin/cp: failed to get attributes of 'kernels': No such file or directory
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Unfortunately cargo-install doesn't accept --target-dir, so have to pass
setting through envvar.
Also %{shrink:…} them so it looks nicer in build log.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Reason this has not been done before is that cargo-install doesn't
understand --release. Let's just add it to other commands and be done
with it.
Reported-by: Josh Stone <jistone@redhat.com>
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
cargo-package automatically strips it out, but we package also some
things directly from git.
Acked-by: Josh Stone <jistone@redhat.com>
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
It is quite useful to see all failing tests instead of few of first.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Reviewed-by: Josh Stone <jistone@redhat.com>
On systems where rustup is used, simple rpmbuild will use rustc from system,
but rustdoc will be taken from PATH which might be different from system.
Given this, doc-tests or anything related to rustdoc will fail with mis-mathching
rustc version.
Merges: https://pagure.io/fedora-rust/rust2rpm/pull-request/38
We should not be using /usr/src because that one is supposed to be used for
"Source code may be placed in this subdirectory, only for reference purposes".
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Since rustc doesn't allow `-g` and `-Cdebuginfo` options to mix, we need
to make sure we're consistent with the option crates may set in their
own `[profile] debug` settings. Cargo used to send `-g` for that, but
switched to `-Cdebuginfo` in version 0.17.0.
Fixes#32.
cargo package -l lists Cargo.toml.orig and we're installing it anyway,
so let's just do mv -f instead of doing new install.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Imagine, that:
* A requires 0.6.0 <= X < 0.7.0
* B requires 0.9.0 <= X < 0.10.0
* C requires A and B
If we use Requires + Conflicts, then we just can't build or install
C, because sub-dependencies are conflicting between each other.
Proper syntax is: (X >= 0.6.0 with X < 0.7.0)
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
All background written in upstream cargo GitHub issue[0].
In short, cargo build/install enforces us to have all dev-dependencies
even they are not used for building/installed.
[0] https://github.com/rust-lang/cargo/issues/3732
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
So far we had %cargo_install (for binaries) and %cargo_install_crate
(for libraries) which is a bit awkward and requires us to put
additional arguments for latter one.
We can do all the magic behind the scene.
Closes: https://pagure.io/fedora-rust/rust2rpm/issue/7
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
