Re: Some more rust/cargo insights

[Hartmut Goebel <h.goebel@crazy-compilers.com>]

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 |