[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-2.0 v2] tests: Don't run qom-test twice
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH for-2.0 v2] tests: Don't run qom-test twice |
Date: |
Fri, 25 Apr 2014 08:52:21 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) |
Andreas Färber <address@hidden> writes:
> Am 24.04.2014 16:34, schrieb Peter Maydell:
>> On 24 April 2014 15:29, Stefan Hajnoczi <address@hidden> wrote:
>>> On Mon, Apr 07, 2014 at 04:13:00PM +0200, Andreas Färber wrote:
>>>> Commit 3687d5325 accidentally resulted in running qom-test twice
>>>> for x86_64, once directly via the wildcard, and once because x86_64
>>>> includes all the i386 qtests (which includes qom-test).
>>>>
>>>> Filter out x86_64 as well as microblazeel and xtensaeb to fix this.
>>>>
>>>> Cc: Peter Maydell <address@hidden>
>>>> Signed-off-by: Andreas Färber <address@hidden>
>>>> ---
>>>> v1 (PMM) -> v2:
>>>> * Instead of sorting all qtests, leave the order intact and just filter
>>>> the three affected architectures out.
>>>>
>>>> tests/Makefile | 4 +++-
>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> Didn't make it into 2.0 but...
>>>
>>> Reviewed-by: Stefan Hajnoczi <address@hidden>
>>
>> Personally I prefer the "just sort-and-uniquify"
>> approach. This patch introduces an explicit list of
>> architectures which need to be special case, which
>> means that if we ever add a future arch variant which
>> also needs this special casing we need to update the
>> list. The sort patch doesn't have this requirement --
>> it will just work for both this and for any other
>> reason why we might end up with a test in the list
>> multiple times.
>
> Your dislike is why I didn't apply it for 2.0. However, a) the
> inheritance of tests for these three architectures is already an
> explicit statement in the Makefile and more severely b) by sorting the
> list, tests newly added get lost in the gcov stdout chatter (leading to
> even less verification of correctness) and we cannot sensibly order
> tests to first cover, say, PCI host bridge and then PCI devices
> depending on it.
>
> I already asked you for an alternative way of automatically stripping
> duplicates without changing their order, to no avail.
Or append a new element to a list only if not already present. Entirely
untested:
$(if $(word $(words $(sort $(list) $(elt)), $(list))), \
$(list), $(list) $(elt))