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
