On 10-09-2022 19:38, jgart wrote:
On Sat, 10 Sep 2022 18:17:50 +0200 Maxime Devos <maximede...@telenet.be> wrote:Caveat: the ‘examples’ and ‘benchmarks’ functionality is unlikely to be implemented by me (even though they may be useful for development) as they don't bring much value to Guix packaging. [insert the usual patches welcome here]I'm mostly wondering how we would get the rust community to adopt our rust tooling for serious rust development. Do we expect rust people to use Guix for developing rust projects without cargo?
A next step I had in mind, was to separate some functionality of antioxidant-build-system into a Guix-independent 'antioxidant' Guile program, that can also be used by other distro's.
Then Rust people could do things like: $ apt-get install rust-foo ... $ antioxidant configure $ antioxidant build $ antioxidant check $ antioxidant install or $ guix shell -D some-app $ antioxidant configure $ antioxidant build $ antioxidant check $ antioxidant installor whatever. Basically, separate 'package management' from 'building software' -- the former needs the latter, and the latter doesn't really care how packages are managed as long as it is told where to find the dependencies.
I don't think we should expect rust people to use Guix or antioxidant though -- it would be nice if rust people found antioxidant and Guix useful, but if they use Cargo, that's fine too for us.
(Not recommended though, because of the usual problems with single-language package managers and their registries.)
Are there other package managers in the rust community that people are using besides cargo?
Maybe bazel: https://github.com/mrboatsman/rust_bazel_hello_world (seems to be a mix of a package manager and a build system).
Also maybe crane: https://github.com/ipetkov/crane/blob/
I realize cargo has issues. I don't have a comprehensive list of them but I'm curious to find out more.Maxime, what have you researched with regards to cargo issues or where should I start studying up on that to get familiar with why antioxidant is needed? Is there a thread that introduces the need for a new rust build system and why?
There are: * https://lists.gnu.org/archive/html/guix-devel/2022-03/msg00269.html * https://lists.gnu.org/archive/html/guix-devel/2022-08/msg00194.html but I don't think they are good introductions. Anyway, for Guix, some of the main issues are: * overly picky versions requirements -- the rust-cbindgen-VERSION crates are (at least, sufficiently) backwards-compatible. * dependencies like "rust-windows-..." must be packaged even when not compiling for Windows. * cargo is inefficient -- if you compile FOO which depends on BAR having the feature "a" enabled, and later compile FOO2 which wants the feature "b", then IIUC FOO2 is compiled twice, once with "a" and then with "b". How about compiling it once instead, with both "a" and "b". * cargo-build-system is inefficient -- if you do "guix build this-app", and then do "guix build that-app", then the compiled dependencies of "this-app" cannot be reused for "that-app". Cargo does not seem to have an option to ... not do that. Even if it did, there is the previous issue with 'features'. (Crane seems to somehow tell Cargo how to not do that, but it still appears to have the feature problem and it heavily depends on crates.io or Cargo.lock, not really suitable for distros). Greetings, Maxime.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature