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
Hi,
I wrote a patch for tito to support Rust package manager (Cargo): https://github.com/dgoodwin/tito/pull/238
I'd like to write an article about it, but in nutshell it's meant to be used with copr, so you can set up a webhook for your github repository and Copr will automatically build a package on push event.
Anyway you have to write spec file yourself.
Best regards,
On Mon, 2017-01-30 at 09:29 +0000, Fabio Valentini wrote:
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:
- Is there support for building and distributing rust libraries as
shared libraries (.so files), if the crate supports it?
As far as I know at this moment it doesn't really work properly and it is also hard to support "features" because either you should build shared library with support for all features or you build with minimal and it seems not good idea.
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. ;)
- Is there a tool for generating .spec files / srpms from crates
(like gofed, but nicer), and is such a tool planned?
Not yet and probably it will be very simple since I want to have all BuildRequires/Requires/Provides generation in RPM and not in some external tools. So work on this tool will be just get version, summary and create spec from very simple template.
If nobody has started working on that yet, I'd volunteer. It sounds like a fun project!
Stop by our IRC channel and we can discuss it ;)
.html
Fabio _______________________________________________ Rust mailing list -- rust@lists.fedoraproject.org To unsubscribe send an email to rust-leave@lists.fedoraproject.org
On Mon, Jan 30, 2017 at 11:19 AM Igor Gnatenko < ignatenkobrain@fedoraproject.org> wrote:
On Mon, 2017-01-30 at 09:29 +0000, Fabio Valentini wrote:
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:
- Is there support for building and distributing rust libraries as
shared libraries (.so files), if the crate supports it?
As far as I know at this moment it doesn't really work properly and it is also hard to support "features" because either you should build shared library with support for all features or you build with minimal and it seems not good idea.
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. ;)
- Is there a tool for generating .spec files / srpms from crates
(like gofed, but nicer), and is such a tool planned?
Not yet and probably it will be very simple since I want to have all BuildRequires/Requires/Provides generation in RPM and not in some external tools. So work on this tool will be just get version, summary and create spec from very simple template.
How can RPM generate BuildRequires - solely from the source archive? Even if that could work (in the future?), doing it that way would be make the whole process too opaque to packagers in my opinion ...
If nobody has started working on that yet, I'd volunteer. It sounds like a fun project!
Stop by our IRC channel and we can discuss it ;)
I'll do that when I have some time!
.html
Fabio _______________________________________________ Rust mailing list -- rust@lists.fedoraproject.org To unsubscribe send an email to rust-leave@lists.fedoraproject.org
-- -Igor Gnatenko
On Mon, 2017-01-30 at 11:06 +0000, Fabio Valentini wrote:
On Mon, Jan 30, 2017 at 11:19 AM Igor Gnatenko < ignatenkobrain@fedoraproject.org> wrote:
On Mon, 2017-01-30 at 09:29 +0000, Fabio Valentini wrote:
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:
- Is there support for building and distributing rust libraries
as shared libraries (.so files), if the crate supports it?
As far as I know at this moment it doesn't really work properly and it is also hard to support "features" because either you should build shared library with support for all features or you build with minimal and it seems not good idea.
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. ;)
- Is there a tool for generating .spec files / srpms from crates
(like gofed, but nicer), and is such a tool planned?
Not yet and probably it will be very simple since I want to have all BuildRequires/Requires/Provides generation in RPM and not in some external tools. So work on this tool will be just get version, summary and create spec from very simple template.
How can RPM generate BuildRequires - solely from the source archive? Even if that could work (in the future?), doing it that way would be make the whole process too opaque to packagers in my opinion ...
Same way as for generating Requires - it's opaque for packagers. It's really a shame that we don't generate BuildRequires for python/ruby/etc. automatically.
Though there is no support in RPM for generating BuildRequires at this point, but I'm discussing it with RPM maintainers and looks like that they (at least Florian) like this idea[0]. [0] http://lists.rpm.org/pipermail/rpm-ecosystem/2017-January/000448.ht ml
On Mon, Jan 30, 2017 at 12:11 PM Igor Gnatenko < ignatenkobrain@fedoraproject.org> wrote:
On Mon, 2017-01-30 at 11:06 +0000, Fabio Valentini wrote:
On Mon, Jan 30, 2017 at 11:19 AM Igor Gnatenko < ignatenkobrain@fedoraproject.org> wrote:
On Mon, 2017-01-30 at 09:29 +0000, Fabio Valentini wrote:
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:
- Is there support for building and distributing rust libraries
as shared libraries (.so files), if the crate supports it?
As far as I know at this moment it doesn't really work properly and it is also hard to support "features" because either you should build shared library with support for all features or you build with minimal and it seems not good idea.
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. ;)
- Is there a tool for generating .spec files / srpms from crates
(like gofed, but nicer), and is such a tool planned?
Not yet and probably it will be very simple since I want to have all BuildRequires/Requires/Provides generation in RPM and not in some external tools. So work on this tool will be just get version, summary and create spec from very simple template.
How can RPM generate BuildRequires - solely from the source archive? Even if that could work (in the future?), doing it that way would be make the whole process too opaque to packagers in my opinion ...
Same way as for generating Requires - it's opaque for packagers. It's really a shame that we don't generate BuildRequires for python/ruby/etc. automatically.
With the difference that Requires are generated after the build and are needed after the build - BuildRequires would be generated FROM the build and needed before the build, so that is kind of a bootstrap problem, if the process is not changed (split into two phases).
BuildRequires are read from .spec and installed before %prep is executed, so not even an unpacked (and maybe patched) source is available at that point.
I don't see how auto-generating BuildRequires could work without invasive changes in the way RPMs are built, for example needing two phases of installing BuildRequires installs instead of one (Install Phase 1: the BRs explicitly specified in the .spec file are installed, then the sources are unpacked and processed, and Install Phase 2: install phase with the determined BRs?).
Though there is no support in RPM for generating BuildRequires at this point, but I'm discussing it with RPM maintainers and looks like that they (at least Florian) like this idea[0]. [0] http://lists.rpm.org/pipermail/rpm-ecosystem/2017-January/000448.ht ml http://lists.rpm.org/pipermail/rpm-ecosystem/2017-January/000448.html -- -Igor Gnatenko
On Mon, 2017-01-30 at 12:46 +0000, Fabio Valentini wrote:
On Mon, Jan 30, 2017 at 12:11 PM Igor Gnatenko < ignatenkobrain@fedoraproject.org> wrote:
On Mon, 2017-01-30 at 11:06 +0000, Fabio Valentini wrote:
On Mon, Jan 30, 2017 at 11:19 AM Igor Gnatenko < ignatenkobrain@fedoraproject.org> wrote:
On Mon, 2017-01-30 at 09:29 +0000, Fabio Valentini wrote:
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:
- Is there support for building and distributing rust
libraries as shared libraries (.so files), if the crate supports it?
As far as I know at this moment it doesn't really work properly and it is also hard to support "features" because either you should build shared library with support for all features or you build with minimal and it seems not good idea.
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. ;)
- Is there a tool for generating .spec files / srpms from
crates (like gofed, but nicer), and is such a tool planned?
Not yet and probably it will be very simple since I want to have all BuildRequires/Requires/Provides generation in RPM and not in some external tools. So work on this tool will be just get version, summary and create spec from very simple template.
How can RPM generate BuildRequires - solely from the source archive? Even if that could work (in the future?), doing it that way would be make the whole process too opaque to packagers in my opinion ...
Same way as for generating Requires - it's opaque for packagers. It's really a shame that we don't generate BuildRequires for python/ruby/etc. automatically.
With the difference that Requires are generated after the build and are needed after the build - BuildRequires would be generated FROM the build and needed before the build, so that is kind of a bootstrap problem, if the process is not changed (split into two phases).
BuildRequires are read from .spec and installed before %prep is executed, so not even an unpacked (and maybe patched) source is available at that point.
I don't see how auto-generating BuildRequires could work without invasive changes in the way RPMs are built, for example needing two phases of installing BuildRequires installs instead of one (Install Phase 1: the BRs explicitly specified in the .spec file are installed, then the sources are unpacked and processed, and Install Phase 2: install phase with the determined BRs?).
Don't worry, we discussed this with RPM developers and they are aware of this and feel free to read rpm-ecosystem@ about any further discussions about this.
Though there is no support in RPM for generating BuildRequires at this point, but I'm discussing it with RPM maintainers and looks like that they (at least Florian) like this idea[0]. [0] http://lists.rpm.org/pipermail/rpm-ecosystem/2017-January/00044 8.ht ml http://lists.rpm.org/pipermail/rpm-ecosystem/2017-January/00044 8.html -- -Igor Gnatenko
On 01/30/2017 01:29 AM, Fabio Valentini wrote:
- 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. ;)
The biggest problem is that Rust has no defined ABI: https://github.com/rust-lang/rfcs/issues/600
I've written about this before, several times, for instance here: https://bugzilla.redhat.com/show_bug.cgi?id=915043#c68
The gist is that while static linking is painful, dynamic linking on an unstable ABI is even worse.
Now, that's only for Rust<->Rust. In the case of FFI, you're actually using a C ABI, and this should be fine. Dynamic linking should be preferred for both Rust making FFI calls and for Rust providing FFI for other languages to call.
For the latter, the crate should either build as a "cdylib", or emit objects or a staticlib that's later linked into a larger .so, like the latest librsvg is doing. https://github.com/GNOME/librsvg/tree/master/rust
Hmm, that's an old version of the book, and FWIW that section appears to be chopped from the current version. There's still the FFI chapter, but it only has a brief section on calling into Rust: https://doc.rust-lang.org/book/ffi.html#calling-rust-code-from-c
On Mon, Jan 30, 2017 at 9:01 PM Josh Stone jistone@redhat.com wrote:
On 01/30/2017 01:29 AM, Fabio Valentini wrote:
- 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. ;)
The biggest problem is that Rust has no defined ABI: https://github.com/rust-lang/rfcs/issues/600
I've written about this before, several times, for instance here: https://bugzilla.redhat.com/show_bug.cgi?id=915043#c68
The gist is that while static linking is painful, dynamic linking on an unstable ABI is even worse.
I agree.
Now, that's only for Rust<->Rust. In the case of FFI, you're actually
using a C ABI, and this should be fine. Dynamic linking should be preferred for both Rust making FFI calls and for Rust providing FFI for other languages to call.
Exactly, the FFI case is the one I am a bit worried about. It's not feasible for every package wanting to use a rust crate via a FFI to build (as cdylibs) and bundle the needed crates.
For the latter, the crate should either build as a "cdylib", or emit
objects or a staticlib that's later linked into a larger .so, like the latest librsvg is doing. https://github.com/GNOME/librsvg/tree/master/rust
[0]:
https://doc.rust-lang.org/1.5.0/book/rust-inside-other-languages.html
Hmm, that's an old version of the book, and FWIW that section appears to be chopped from the current version. There's still the FFI chapter, but it only has a brief section on calling into Rust: https://doc.rust-lang.org/book/ffi.html#calling-rust-code-from-c
Oops, my bad, I just googled the topic and didn't notice that the version is old. It's still in the book though (somewhat shortened, as you said).
Rust mailing list -- rust@lists.fedoraproject.org To unsubscribe send an email to rust-leave@lists.fedoraproject.org
On 01/30/2017 12:11 PM, Fabio Valentini wrote:
Now, that's only for Rust<->Rust. In the case of FFI, you're actually using a C ABI, and this should be fine. Dynamic linking should be preferred for both Rust making FFI calls and for Rust providing FFI for other languages to call.Exactly, the FFI case is the one I am a bit worried about. It's not feasible for every package wanting to use a rust crate via a FFI to build (as cdylibs) and bundle the needed crates.
OK, but I'm not sure why you're worried about this. If a crate is providing FFI, that part should be built and shipped as a .so just like any other rpm library.
I mean, we haven't formalized Rust packaging yet, but this will need to be part of it. We're talking about source-based devel packages for general Rust libraries, statically linked, but FFI should be treated like any other provided library in Fedora.
On Mon, Jan 30, 2017 at 9:19 PM Josh Stone jistone@redhat.com wrote:
On 01/30/2017 12:11 PM, Fabio Valentini wrote:
Now, that's only for Rust<->Rust. In the case of FFI, you'reactually
using a C ABI, and this should be fine. Dynamic linking should be preferred for both Rust making FFI calls and for Rust providing FFIfor
other languages to call.Exactly, the FFI case is the one I am a bit worried about. It's not feasible for every package wanting to use a rust crate via a FFI to build (as cdylibs) and bundle the needed crates.
OK, but I'm not sure why you're worried about this. If a crate is providing FFI, that part should be built and shipped as a .so just like any other rpm library.
That sounds good. Thanks for the explanation :)
I mean, we haven't formalized Rust packaging yet, but this will need to be part of it. We're talking about source-based devel packages for general Rust libraries, statically linked, but FFI should be treated like any other provided library in Fedora.
I understand. I was just reminded of just how awkward golang packaging can be ...
-
Fabio Valentini -
Igor Gnatenko -
Josh Stone -
Martin Sehnoutka