Re: rust (build system) deficits

[John Soo]

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