Hey Fabio,
On 11/06/2021 15.38, Fabio Valentini wrote:
On Fri, Jun 11, 2021 at 6:28 AM Fabio M. Di Nitto <fdinitto@xxxxxxxxxx> wrote:
Hey everyone,
I have been reading the current guideline here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/
and for the most it´s pretty clear when packaging a standalone crate /
rust generated binaries (given this is my very first step into
understanding rust).
I am currently facing a slightly different challenge as my upstream
project, a bunch of C shared libraries (also available in Fedora), will
soon grow rust bindings.
The rust code will be part of the normal upstream tarball / etc. that
will include at that point a mix of different languages.
The upstream build system already takes care to call into cargo for
example and I am wondering how the current rust rpm macros are going to
work with it (or viceversa).
Does anyone have experience in packaging mixed sources?
Could you share your spec file please (or just the srpm name ;))
Hello,
I think this depends on how the upstream project works.
This is totally up for discussion and changes. So far the PR I have
received includes the rust bindings and a basic integration to the build
system.
We can change it as needed to fit the best way to deal with Rust, that´s
why I am seeking advice and to make sure upstream makes it super easy
for downstream to deal with those bindings.
The upstream build system already takes care to call into cargo for
example and I am wondering how the current rust rpm macros are going to
work with it (or viceversa).
What toes "the upstream build system already takes care to call into
cargo" mean?
For Rust packages, we only package sources, but no compiled libraries
/ rlib files (since there is no stable ABI).
At the moment we call into cargo build to build both the bindings and
the test suite to test the bindings within the current build.
Good to know about sources, that´s "easy" to package.
Does running "make install" (or your buildsystem's equivalent) run
"cargo install" as well? I'm not even sure that this works for
"source-only" libraries.
Not yet. This is the point when I stopped and asked myself: How should I
install it and make it ready for packaging / shipping?
Keep in mind that my knowledge of rust is close to 0 at this point. I am
trying to understand and build some knowledge to do the right thing.
As Rich points out, the easiest solution would probably be to publish
the Rust bindings separately, preferably as a standalone crate on
crates.io.
Crates from crates.io can usualyl be packaged with an effort of a few
minutes. Manually making sure that Rust bindings from a shared source
tree get installed correctly would probably be a brittle solution that
is prone to break with updates to kronosnet itself or changes to the
Rust macros in Fedora.
Understood I think...
However, *if* you want to go the route of "install everything from the
shared source tree", beware that the Rust macros were only intended to
work on crate sources.
gotcha. I am fine with whatever everyone else is doing and do it right.
I have 0 opinion (based on my 0 knowledge) on what route to take :)
There are a few things you need to keep in mind:
- %cargo_prep needs to be called in %prep in the crate's root
directory, and will override any existing .cargo/config files. This is
used to set up /usr/share/cargo/registry as crates.io replacement.
- %cargo_generate_buildrequires needs to be called in
%generate_buildrequires, in each crate's root directory. This will
automatically generate the necessary BuildRequires for crate
dependencies.
- %cargo_build will try to build your Rust bindings, usually you'd
want that to happen in %build
- %cargo_install will copy the crate's source tree(s) to the
appropriate location in /usr/share/cargo/registry so other Rust crate
packages can use them.
- %cargo_test will compile and run all tests that are present in the
crates (usually in %check)
got it.
The only Fedora package that successfully integrates something similar
is python-cryptography, however, this package does not ship Rust
bindings, but instead contains a binary Rust plugin that the python
module calls into, so you'd have to modify what that package does for
your needs as well.
So, TL;DR: If possible, publish the Rust bindings separately as a
crate on crates.io. It should be way easier to package and maintain
that way.
I think we can do that :)
Thanks again
Fabio
Fabio
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
