guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how does antioxidant work?


From: Maxime Devos
Subject: Re: how does antioxidant work?
Date: Sat, 10 Sep 2022 20:15:22 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0



On 10-09-2022 19:38, jgart wrote:
On Sat, 10 Sep 2022 18:17:50 +0200 Maxime Devos <maximedevos@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 install

or 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.

Attachment: OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]