Il sab 20 mag 2023, 17:13 Ani Sinha <anisi...@redhat.com> ha scritto:
> > On 20-May-2023, at 3:06 PM, Paolo Bonzini <pbonz...@redhat.com> wrote:
> >
> >
> >
> > Il sab 20 mag 2023, 09:25 Ani Sinha <anisi...@redhat.com> ha scritto:
> > 40c909f534e3f3cd2 from what I can see. It requires a full QEMU build in
> order to turn on CONFIG_IASL in bios-tables-test. At some point in the
> past, we could just install iasl and rerun the test and it would discover
> iasl in the path if CONFIG_IASL was not defined.
> >
> > So you want CONFIG_IASL to *not* have the full path if you configure
> with --iasl=iasl?
>
> Iasl is *not* a mandatory tool to run that test. So we do not want any
> configure option at all. It is absolutely not needed and makes the entire
> workflow more burdensome.
>
Configure is the default place where people look for an option to customize
binaries. A magic environment variable is hard to discover.
What you want is:
- default is iasl
- default can be overridden with --iasl
Implemented as:
iasl = find_program(get_option('iasl'), required: false)
if iasl.found()
config_host_data.set_quoted('CONFIG_IASL', iasl.full_path()
ending
- IASL environment variable wins
- if neither the preprocessor macro nor the environment variable is
present, the test is skipped
Paolo
>
> > Paolo
> >
> >
> > I have proposed a patch with the title "acpi/tests/bios-tables-test:
> pass iasl path through environment variable”.
> > I have tested possible scenarios and it would satisfy my uneasiness. One
> thing I could not find is how to discover OS environment variable from
> meson.build. From what I could gather, currently it is not supported.
> Hence, when both CONFIG_IASL is passed from the command line and meson
> discovers one of its own, the meson one would be enforced and not the one
> developer passed.
> >
> >
>
>
