Igor Mammedov <imamm...@redhat.com> writes:
> On Thu, 15 Jul 2021 07:49:13 +0200
> Markus Armbruster <arm...@redhat.com> wrote:
>
>> Philippe Mathieu-Daudé <phi...@redhat.com> writes:
>>
>> > On 7/14/21 4:43 PM, Markus Armbruster wrote:
>> >> Philippe Mathieu-Daudé <phi...@redhat.com> writes:
>> >>
>> >>> +Markus
>>
>> [...]
>>
>> >>> IMO the "right" solution is to check via QMP if TMP is supported
>> >>> or not. This is now doable since commit caff255a546 ("tpm: Return
>> >>> QMP error when TPM is disabled in build").
>> >>>
>> >>> Long term we'd like to decouple the tests/ build from the various
>> >>> QEMU configurations, and build the tests once.
>> >>
>> >> This argument applies only to macros from target-specific headers like
>> >> $TARGET-config-target.h, not to macros from config-host.h. #ifdef
>> >> CONFIG_TPM should be fine, shouldn't it?
>> >
>> > Some definitions depend on the host (OS, libraries installed, ...),
>> > others depend on the --enable/--disable ./configure options.
>> >
>> > IMO it would be nice if we could get qtests independent of the latter.
>>
>> Why?
>
> In another mail-thread Philippe mentioned that there is desire
> to use qtest out of tree to test other QEMU binaries.
>
> However, just probing for features at runtime aren't going
> to help with the goal as tests are tailored for the latest
> CLI/QMP/ABI. To make it work we would have practically
> introduce versioned tests.
>
> So I wonder why one external acceptance-tests suite is not
> sufficient, that we would want to hijack relatively simple
> internal qtest at expense of increased resources needed to
> run/write unit tests.
Yes. qtest was not designed for use with anything but HEAD, and I doubt
we can make it fit such uses at reasonable expense.
>
>> > I suppose config-host.h holds both kinds.
>>
>> Yes.
>>
>>
