> On 20-May-2023, at 3:06 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
>
> Il sab 20 mag 2023, 09:25 Ani Sinha <anisinha@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.
>
>