The config file already allows to specify unwanted-features. It would be reasonable to add support for enabling optional features as well, e.g.
all-features = true
enable-features = foo bar baz
This would also serve as a partial workaround for #110, allowing to store the state of an optional feature with binaries between rust2rpm invocations.
#183 didn't actually end up addressing this problem.
However, we have recently added support for setting all-features = true, which addresses your first use case.
all-features = true
I've been thinking about the second case (where only certain features need to be enabled for some steps of the build), and I'm not sure how to best address this as a setting. But the most flexible solution for me would be something like this:
It is slightly more verbose, but it would allow setting different features for the different stages of the build process (for example, if some feature only needs to be enabled for tests, like a ci feature).
However, this also has the potential to be used to create slightly broken .spec files (for example, not enabling a feature in %cargo_build but enabling it in %cargo_test might give unexpected failures or cause unnecessary recompilation to happen).
Using the simpler approach would solve this problem:
This does not offer the same level of granularity (which is, in general, not needed anyway), but would work around the "possible inconsistency problem" that the more fine-grained approach would suffer from.
Ideally, we'd read the "required-features" settings for binaries and generate -f foo,bar flags for all %cargo_* macros automatically. And if tests are enabled (which they are, by default), we'd need to read the "required-features" settings for all examples and test binaries as well.
That reminds me, we should have a setting + CLI switch for defaulting to %with_check (and ideally, supplying a reason string that can be included in the .spec file). That's one of the few things that aren't automated / persistent with a setting in rust2rpm.conf yet ...
Metadata Update from @decathorpe:
- Issue set to the milestone: 23
to comment on this ticket.