Rust SIG? Count me in!
by Fabio Valentini
Hi Guys,
I've been interested in Rust for some time now (and even more, now that
I've learned about functional programming and studied the lambda calculus
at university ;)
I have 2 questions regarding the state and future of Rust on fedora:
1) Is there support for building and distributing rust libraries as shared
libraries (.so files), if the crate supports it?
If not, this could lead to at least one problem ... any software package
using a rust library via a FFI (as described at [0]) would have to build
the crate itself and bundle the library. I don't think this is feasible in
the long run (every package having to build the create itself and every
package having to include the .so file looks like a lot of wasted work,
time and space to me).
Additionally, I generally dislike linking everything statically (like
golang does), and would much prefer if fedora supported building and
distributing rust libraries from the start. ;)
2) Is there a tool for generating .spec files / srpms from crates (like
gofed, but nicer), and is such a tool planned?
If nobody has started working on that yet, I'd volunteer. It sounds like a
fun project!
[0]: https://doc.rust-lang.org/1.5.0/book/rust-inside-other-languages.html
Fabio
7 years, 2 months
Boolean dependencies vs self-provides (for rust "features" support)
by Igor Gnatenko
```toml
[dependencies]
bitflags = "~0.7"
ansi_term = { version = "~0.9.0", optional = true }
term_size = { version = "~0.2.0", optional = true }
libc = { version = "~0.2.9", optional = true }
[features]
default = ["color", "wrap_help"]
color = ["ansi_term", "libc"]
wrap_help = ["libc", "term_size"]
```
Since we are packaging source code, -devel package will have `Requires:
crate(bitflags)`. But applications (which are built out of this sources
statically) can request features which this source is exposing and it
means that it should pull additional dependencies.
Syntax for such dependencies is like:
```toml
[dependencies]
clap = { version = "2.19.2", features = ["yaml"] }
```
Obviously, first thing which is coming to mind is to specify provides
for features and use rich dependencies for requirements, something
like:
```
Provides: crate(clap)
Provides: crate(clap)(color)
Requires: ((crate(ansi_term) and crate(libc)) if crate(clap)(color))
Provides: crate(clap)(wrap_help)
Requires: ((crate(libc) and crate(term_size)) if
crate(clap)(wrap_help))
```
But it doesn't work since it works the RPM thinks that crate(clap)(xxx)
is going to be installed (since it's provided by same package) so it
requires other packages to be installed as well which is something not
what we want.
Probably for now sane way would be just require all optional packages
to cover *all* features which package provides, but it means that
builds will be slow because they would need to pull a lot of packages
always.
P.S. I omit version stuff to make examples more easy.
P.P.S. ignore `default` feature for now since I'm not sure how exactly
it works in rust/cargo ecosystem at this moment.
--
-Igor Gnatenko
7 years, 2 months
Automatic BuildRequires
by Igor Gnatenko
This topic is not very much interesting for C/C++/D/etc. languages, but
very interesting for Python, Ruby and Rust ecosystems.
In those ecosystems you can get build-time and test-time dependencies
very easily since metadata is pre-populated (doesn't matter how) and
you just need to parse it, but RPM doesn't support generating
BuildRequires.
As we discussed some time ago with Panu and Florian on IRC this task
splits to 2 different blocks:
1. Pre-BuildRequires -- everything what needs to be installed in order
to unpack archive and parse metadata
2. Make building of SRPM a bit more tricky: first time to build
something what can gather builddeps and then generate full SRPM with
all that stuff.
I was thinking a bit if we should really make different section for
only for generating builddeps (as Panu was asking) and I think it's not
needed and we can (or probably even should) reuse -- for example,
upstream provides wrong metadata (redundant requires or very strict
version which you want to relax), you do sed/patch in %prep and it
should be both same for BuildRequires generation and for real build.
Another question here as well is how do you generate test builddeps:
since we don't have BuildRequires(check), we probably would need to
have BuildRequires and TestRequires generator... but I'm not sure how
to wrap it properly.
Thoughts?
--
-Igor Gnatenko
7 years, 2 months