Re: rust (build system) deficits

[John Soo <jsoo1@asu.edu>]

Hi Hartmut,

I agree with you. It seems like a problem for cargo to solve to me.  Efraim tried to use the .rlib files to make library files and found it was not really an option.

There are more problems, too. The way inputs are done doesn’t fit well with the rest of guix tooling and doesn’t really follow functional package management concepts.

One possibility to try is to rethink the cargo-{development-}inputs fields and only require the source from rust library inputs. Then to build the executables, it would only require one compile and we could keep ci checking the current libraries.

The cargo build system also has a specialized transitive closure computation. I believe the reason cargo-{development-}inputs are specified in arguments is for the special purpose of that closure computation. Can someone tell me if I’m wrong on that?

As far as I can tell, the point of the specialized transitive closure computation is to deal with cyclic dependencies.  Again, please someone correct me if I’m wrong on that.

If the rust closure functions successfully deal with cyclic dependencies, then wouldn’t the other closure computations benefit from the same function?

I would like to take a stab at bringing the rust build system package definitions closer to others.

My proposal is to:
* move cargo-{development-}inputs into inputs, requiring only the source from libraries.
* either:
  - move the rust closure function so all packages use it
Or
  - adjust the transitive closure function such that it works on normal inputs rather than arguments
* Do not build rust packages by default. Only run tests.
* as a corollary to the previous item: Default skip-build? to #f but do run tests even if skip-build is #f and tests? is #t

What do you all think, Hartmut, guix?

- John