On 16 Feb 2022 07:24, Hans-Peter Nilsson wrote:
> 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.

i think you misunderstand.  you're basically running:
  run --help | grep -e--option
where --option is some functionality you care about.

i'm saying --help is not an interface.  it should be free to change and
reformat things as makes sense and not worry about testsuites breaking.
in the case of a multitarget binary, we probably wouldn't display all the
options in a single page, but have arch-specific sections.

i'm proposing:
  run --do-command version | grep <feature>
where in this case you seem to care about hardware support being enabled.
so the test would look like:
  # requires: simoption WITH_HW
and then the code would look for that in the structured output produced
by the sim config output (which is included in the extended version).
-mike