Re: [PATCH 06/12] sim/testsuite: Support "requires: simoption <--name-of-option>"

[Hans-Peter Nilsson <hp@axis.com>]

> Date: Tue, 15 Feb 2022 23:49:47 -0500
> From: Mike Frysinger <vapier@gentoo.org>

> On 15 Feb 2022 00:03, Hans-Peter Nilsson via Gdb-patches wrote:
> > Simulator features can be present or not, typically
> > depending on different-valued configure options, like
> > --enable-sim-hardware[=off|=on].  To avoid failures in
> > test-suite-runs when testing such configurations, a new
> > predicate is needed, as neither "target", "progos" nor
> > "mach" fits cleanly.
> > 
> > The immediate need was to check for presence of a simulator
> > option, but rather than a specialized "requires-simoption:"
> > predicate I thought I'd handle the general (parametrized)
> > need, so here's a generic predicate machinery and a (first)
> > predicate to use together with it; checking whether a
> > particular option is supported, by looking at "run --help"
> > output.  This was inspired by the check_effective_target_
> > machinery in the gcc test-suite.
> 
> i really don't want --help to be an API surface like this.  it's the wrong
> layer for the job.
> 
> we have a sim_config_print function which dumps configuration information.
> i'd be fine making that the surface to build off of.  i don't think we
> print hardware there atm, but should be trivial to introduce.
> 
> only other missing piece is that it's not obvious how to access it from
> the CLI.  `run --version` doesn't include it.  `run --do-command version`
> does though :x.  i'd be amenable to improving this interface, either by a
> new option like --info-config</bikeshed> or some other route.

But, "run --version" is a check for the *option* to exist,
which exactly meets the need.  You describe a probe for a
particular *configuration*, which is arguably useful, but
not for checking whether a particular option is supported.

brgds, H-P