Hartmut Goebel schreef op wo 06-04-2022 om 17:49 [+0200]:

> [...]
> >     * Package definitions can request non-default features to be built
> >       anyway.
> > 
> >       A difference from cargo-build-system: features are set in the
> >       package of the rust crate, not the package using the rust crate.
> 
> How is this intended to work?
> 
> Package 1 has features AAA (= default) and BBB. So a .rlib is build for 
> each feature (package1-AAA.rlib, package1-BBB.rlib) Or will one need to 
> define two guix packages (package1+aaa and package1+bbb) and make the 
> build-system build the respective feature?
> 
> I personally would prefer the former. Thus package2 would pick up the 
> pre-compiled rlib for the respective feature.
> 
> Rational: If there are more features to be combined, the number of 
> packages to be build can a order of square. So defining all these 
> packages becomes a burden quickly. This is a computer's job :-) The 
> build-system could easily build all combinations. suffixing each rlib 
> with a short hash over the feature names,

My third solution: no package variants, no multiple .rlib variants.
Instead, by default enable the ‘default features’ mentioned in the
Cargo.toml, and (manually) add the extra features to the package
definition of the Rust dependency if they turn out to be needed by the
dependent.

This is like adding --enable-this --enable-that, ... to ffmpeg's
#:configure-flags instead of building a variant of ffmpeg for each
dependent of ffmpeg that needs a different feature set.

So far, I have not encountered incompatible features ... Let's see if
it will become a problem.

Greetings,
Maxime.