[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some more rust/cargo insights
From: |
Hartmut Goebel |
Subject: |
Re: Some more rust/cargo insights |
Date: |
Mon, 7 Jun 2021 18:26:44 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 |
Hi John.
Am 07.06.21 um 17:13 schrieb John Soo:
Rust has a very well documented rfc process and we can at least bring
it up that way. I brought up the possibility of collaboration between
rust and functional package managers on the rust Zulip, even. They
seemed to like the idea.
I'd be more than happy if you could start a RFC process then. This issue
bugs us and other distros since many months. (I have not contact to the
rust community and will not sign up at another proprietary communication
platform (Zulip)).
My feeling on this is that we should partner with the Rust community
to make shared library support from cargo a priority.
Our issue is a different one: Its about being able to reuse already
compiled binaries - keeping current behavior of rust binaries being
statically linked.
While this looks like being the same as dynamic library support, it is
not: While for dynamic libraries you meet to ensure the very correct
version of a "crate" is loaded, for static linking with pre-build
binaries you only need to ensure this at build-time. (For guix, of
course, both would not be a problem, but I doubt we can make rust people
understand this. And other distros will still have the problem.)
rustc already has a notion for "static libraries", just cargo fu** it
up. (Sorry for hard wording, but I'm actually quite angry about cargos'
narrow-minded behavior).
So our task is much, much easier and doesn't require changed to rustc,
only to cargo.
Specifying an output directory is currently a nightly feature, that
could be helpful.
Not exactly sure what you mean. But what breaks build with cargo are the
*input* directories - and other magic which gets included into the
"meta-data" for no reason.
In general Rust tooling does not compose with existing tools. I
believe they will be amenable to the thought that it should. If Rust
wants to be used in the linux kernel, for instance, it should be easy
to use with Make.
From your lips to God's ears. From what I've seen an read, I'm not
convident they will change anything. I'd like to be proofed wrong,
though :-)
Another path we should checkout is to see what Debian does. My
understanding is that they figured something out. Worth a shot, but
I’d rather the problem be fixed upstream. It will just take collaboration.
I did not check their tollchain lately, but package-earch still does not
show many packages
<https://packages.debian.org/search?suite=experimental&searchon=names&keywords=rust>.
Last time I check, they basically do what guix does: compile everything
from source - again and again.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goebel@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
- Some more rust/cargo insights, Hartmut Goebel, 2021/06/06
- Message not available
- Re: Some more rust/cargo insights, Hartmut Goebel, 2021/06/07
- Re: Some more rust/cargo insights, Pjotr Prins, 2021/06/07
- Re: Some more rust/cargo insights, Hartmut Goebel, 2021/06/07
- Re: Some more rust/cargo insights, John Soo, 2021/06/07
- Re: Some more rust/cargo insights, John Soo, 2021/06/07
- Re: Some more rust/cargo insights,
Hartmut Goebel <=
- Re: Some more rust/cargo insights, Hartmut Goebel, 2021/06/07
- Re: Some more rust/cargo insights, Efraim Flashner, 2021/06/08
- Re: Some more rust/cargo insights, Hartmut Goebel, 2021/06/08
Re: Some more rust/cargo insights, Maxim Cournoyer, 2021/06/14