3:29 a.m.
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
3:43 a.m.
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,
--
Martin Sehnoutka | Associate Software Engineer
PGP: 5FD64AF5
UTC+1 (CET)
RED HAT | TRIED. TESTED. TRUSTED.
4:19 a.m.
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:
1) 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. ;)
2) 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 ;)
[0]: https://doc.rust-lang.org/1.5.0/book/rust-inside-other-languages
.html
Fabio
_______________________________________________
Rust mailing list -- rust(a)lists.fedoraproject.org
To unsubscribe send an email to rust-leave(a)lists.fedoraproject.org
--
-Igor Gnatenko
5:06 a.m.
On Mon, Jan 30, 2017 at 11:19 AM Igor Gnatenko <
ignatenkobrain(a)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:
>
> 1) 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. ;)
>
>
> 2) 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!
>
>
>
> [0]: https://doc.rust-lang.org/1.5.0/book/rust-inside-other-languages
> .html
>
> Fabio
> _______________________________________________
> Rust mailing list -- rust(a)lists.fedoraproject.org
> To unsubscribe send an email to rust-leave(a)lists.fedoraproject.org
--
-Igor Gnatenko
5:11 a.m.
On Mon, 2017-01-30 at 11:06 +0000, Fabio Valentini wrote:
On Mon, Jan 30, 2017 at 11:19 AM Igor Gnatenko <
ignatenkobrain(a)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:
> >
> > 1) 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. ;)
> >
> >
> > 2) 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
--
-Igor Gnatenko
6:46 a.m.
On Mon, Jan 30, 2017 at 12:11 PM Igor Gnatenko <
ignatenkobrain(a)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(a)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:
> > >
> > > 1) 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. ;)
> > >
> > >
> > > 2) 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
6:52 a.m.
On Mon, 2017-01-30 at 12:46 +0000, Fabio Valentini wrote:
On Mon, Jan 30, 2017 at 12:11 PM Igor Gnatenko <
ignatenkobrain(a)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(a)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:
> > > >
> > > > 1) 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. ;)
> > > >
> > > >
> > > > 2) 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
--
-Igor Gnatenko
1:50 p.m.
On 01/30/2017 01:29 AM, Fabio Valentini wrote:
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. ;)
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
2:11 p.m.
On Mon, Jan 30, 2017 at 9:01 PM Josh Stone <jistone(a)redhat.com> wrote:
On 01/30/2017 01:29 AM, Fabio Valentini wrote:
> 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. ;)
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(a)lists.fedoraproject.org
To unsubscribe send an email to rust-leave(a)lists.fedoraproject.org
2:19 p.m.
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.
4:16 p.m.
On Mon, Jan 30, 2017 at 9:19 PM Josh Stone <jistone(a)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'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.
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 ...
2426
days inactive
2426
days old
10 comments
4 participants
participants (4)
-
Fabio Valentini -
Igor Gnatenko -
Josh Stone -
Martin Sehnoutka