Re: Compiling rust things without cargo (super WIP POC)

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

> I invite you to take a look at <https://notabug.org/maximed/cargoless-rust-experiments>.
> It contains a minimal rust library (libhello) and a minimal 'hello
> world'-style application that uses 'libhello'.
>
> To simulate how Guix compiles C software (but here applied to Rust), 
> the Makefile does the following:
>
>   * Run 'rustc --crate-type=lib libhello/hello.rs -o out/libhello/lib/libhello.rlib',
>     to compile the library and install it in 'out/libhello/lib/libhello.rlib'
>     (cf. /gnu/store/...-libhello.../lib/hello.so).
>
>   * Run 'rustc -Lout/libhello/lib hello-app/main.rs -o out/hello-oxygen/bin/hello'
>     to compile the application.  By default, rustc will fail because it cannot find
>     the library.  However, if -Lout/libhello/lib is passed, then it does find it!
>
>     (cf. LIBRARY_PATH=/gnu/store/.../lib & gcc -L/gnu/store/.../lib)
>
> This is a rather basic example (no transitive dependencies, no test dependencies,
> no macros ...), but it seems like there are some possibilities here ...

Interesting.

> As a next step, maybe I could try writing a Guix package definition for libhello
> and hello-oxygen, gradually making things more complicated (macros, transitive
> dependencies, some non-toy Rust dependencies, a Guix build system ...)?

I guess the whole question is whether that technique can be made to work
for the vast majority of Rust packages.  I’d suggest working in that
direction: writing a build system as a first step, using it in all the
Rust packages, and analyzing the kinds of problems encountered, with the
goal of estimating the effort it would take to make it work for every
single package.  Easier said than done, I guess.

Overall, I’m afraid Rust packaging is getting out of hands and we’re all
looking elsewhere.  For example, that Rust packages live in their own
separate world means there’s no tooling available, leading to poor QA, a
proliferation of versions of the same packages that never get removed,
and so on.  I think addressing that, for instance with something as I
proposed in <https://issues.guix.gnu.org/53127>, should be high
priority.

Thoughts?

Ludo’.