Hi Michał,
Sure. No worries - Given the trivial nature I'll update the variable
before merging rather than sending a V2 unless there's other feedback
that requires it. :)
On 3/12/24 23:26, Michał Górny wrote:
On Tue, 2024-12-03 at 22:22 +1000, kan...@gentoo.org wrote:
From: Matt Jolly <kan...@gentoo.org>
These variables enable users (though most likely Gentoo developers)
to override the selection of the Rust implementation by the eclass.
This means that _only_ the specified ERUST_SLOT and/or ERUST_TYPE
('source' or 'binary') will be checked for, with the eclass `die`ing
with "No Rust slot satisfying the package's dependencies..." if the
selected impl is not available.
These variables are intended to enable reproducing bugs and testing
packages against specific dev-lang/rust{,-bin} packages; they must
not be set in ebuilds.
Closes: https://bugs.gentoo.org/945752
Signed-off-by: Matt Jolly <kan...@gentoo.org>
---
eclass/rust.eclass | 49 +++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 44 insertions(+), 5 deletions(-)
diff --git a/eclass/rust.eclass b/eclass/rust.eclass
index 71cbb4b24f8c..991a9cdb7f14 100644
--- a/eclass/rust.eclass
+++ b/eclass/rust.eclass
@@ -98,6 +98,26 @@ declare -a -g -r _RUST_SLOTS_ORDERED=(
"1.54.0"
)
+# == user control knobs ==
+
+# @ECLASS_VARIABLE: ERUST_SLOT
+# @USER_VARIABLE
+# @DESCRIPTION:
+# Specify the version (slot) of Rust to be used by the package. This is
+# useful for troubleshooting and debugging purposes; If unset, the newest
+# acceptable Rust version will be used. May be combined with ERUST_TYPE.
+# This variable must not be set in ebuilds.
+
+# @ECLASS_VARIABLE: ERUST_TYPE
+# @USER_VARIABLE
+# @DESCRIPTION:
+# Specify the type of Rust to be used by the package from options:
+# 'source' or 'binary' (-bin). This is useful for troubleshooting and
+# debugging purposes. If unset, the standard eclass logic will be used
+# to determine the type of Rust to use (i.e. prefer source if binary
+# is also available). May be combined with ERUST_SLOT.
+# This variable must not be set in ebuilds.
Could you perhaps add 'OVERRIDE' to the names, to make it clear they're
not supposed to be normally used? Just like we have
PYTHON_COMPAT_OVERRIDE in Python eclasses.
