cargoless-rust-experiments/report

Goals:

  * Reduce rift between Guix and Rust by making Rust packages work
    nicely in Guix.
  * Eliminating #:skip-build? and making compile time faster,
    by not re-compiling dependencies and by reusing compiled dependencies
    in dependents.  (solved)
  * Allow crates to be shared libraries, such that grafting can work
    and maybe for space usage. (not solved yet)
  * regular inputs/native-inputs (solved)

Non-goals:

  * Produce exactly the same binaries with exactly the same dependencies as with
    Cargo.  If you want to reproduce a binary produced with Cargo, use Cargo.
  * Cross-compilation is left for later.

Side-goals: (not the main goal, but partially solved along the way)

  * Having multiple versions of the same dependency is inconvenient for
    antioxidant, so often only the latest version is preserved.
    Less package variants -> less space usage, less compilation time, less
    opportunities for sneaking malware through, less old buggy versions.
  * As part of resolving build failures caused by using antioxidant,
    some crates were updated or added.

Solved issues:

  * <https://issues.guix.gnu.org/25327>
    ‘cargo build-system should be able to filter out target.cfg(windows) dependencies’
  * <https://issues.guix.gnu.org/53127>
    ‘[PATCH RFC] Turning Rust/Cargo inputs into “regular” inputs?’
  * <https://issues.guix.gnu.org/40412>
    ‘cargo-build-system hides the package dependency graph’

    (at least, after transforming the packages appropriately)

  * <https://issues.guix.gnu.org/50015>
    ‘Rust packages are not reproducible’

    (at least, "guix build --check" hasn't failed for me yet)

Avoided issues:
  * <https://issues.guix.gnu.org/42049>
    ‘[PATCH 0/4] build-system/cargo: Propagations across the crate closure.’
  * <https://issues.guix.gnu.org/36470>
    ‘Cargo-build-system guix-vendor does not provide packages correctly 2 levels down’
  * <https://issues.guix.gnu.org/40413>
    ‘Handling source-only dependencies in a generic way’

Pros/cons of antioxidant:
  * pro: less compilation time: when rust-foo is compiled, antioxidant
    only compiles rust-foo and not its dependencies rust-bar0 ... rust-bar200.
  * pro: theoretically less space usage (source code is not copied to the #$output
    and build results of dependencies are linked to).  However: not measured,
    and we're not setting LTO and -Os compilation flags yet.
  * pro: antioxidant just uses inputs/native-inputs, so "guix graph", "guix refresh -l"
    will be useful after transforming existing package definitions.
  * cons: probably not everything of Cargo.toml is implemented yet

Status:
  * Unless they have been broken, the following packages are known to build:

    antioxidated-castor
    antioxidated-dutree
    antioxidated-diffr
    antioxidated-git-absorb
    antioxidated-hex
    antioxidated-hexyl
    antioxidated-ripgrep
    antioxidated-rtss
    antioxidated-sniffglue
    antioxidated-swayhide
    antioxidated-tealdeer

 * I wouldn't know how many fail to build

Next steps :

(a) The antioxidant channel has information on how to transform
    package definitions using cargo-build-sstem to antioxidant-build-system.
    Maybe "guix style" could be taught to perform these changes to
    the source code?

(b) To get a good grasp on what builds/what not, it would be useful
    to build the channel at ci.guix.gnu.org or such.  More concretely,
    the CI would grab all cargo-build-system rust apps from (gnu packages ...),
    feed them to the package transformation procedure 'vitaminate/auto',
    and build the results.  Then we can have a look at a dashboard like
    <https://ci.guix.gnu.org/eval/361030/dashboard>.

(c) Maybe there could be some kind of transition period, where
    'antioxidant.scm' and 'antioxidant-packages.scm' is added
    to the Guix repo, known-to-build packages are replaced by
    their antioxidated variant (using vitaminate/auto) and gradually
    all rust apps are becoming supported by antioxidant.  Finally,
    when all are supported, the "guix style" from (a) could be run
    to clean up the source code?

    Though for now, I would prefer to do something like (b) first.

(d) Implement support for "cdylib" such that things like librsvg can be built.

(e) Make sure the optimisation settings are reasonable (LTO, -Os etc)