[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: antioxidant-build-system can be tested as a channel, + GTK app 'cast
Re: antioxidant-build-system can be tested as a channel, + GTK app 'castor' builds
Tue, 31 May 2022 11:27:26 +0200
Ludovic Courtès schreef op ma 30-05-2022 om 17:26 [+0200]:
To make sure share a common understanding, could you post a summary of:
1. the goals;
2. the status;
3. pros and cons over the status quo and other options (if any!);
4. the next steps.
(notabug.org is down, so I've made a copy at
* 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)
* 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.
‘cargo build-system should be able to filter out target.cfg(windows)
‘[PATCH RFC] Turning Rust/Cargo inputs into “regular” inputs?’
‘cargo-build-system hides the package dependency graph’
(at least, after transforming the packages appropriately)
‘Rust packages are not reproducible’
(at least, "guix build --check" hasn't failed for me yet)
‘[PATCH 0/4] build-system/cargo: Propagations across the crate closure.’
‘Cargo-build-system guix-vendor does not provide packages correctly 2
‘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
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
will be useful after transforming existing package definitions.
* cons: probably not everything of Cargo.toml is implemented yet
* Unless they have been broken, the following packages are known to build:
* 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
(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)
Description: This is a digitally signed message part