qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC v2 2/5] tests: New make target check-source


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH RFC v2 2/5] tests: New make target check-source
Date: Mon, 27 Jun 2016 08:34:50 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Peter Maydell <address@hidden> writes:

> On 24 June 2016 at 15:19, Markus Armbruster <address@hidden> wrote:
>> For now, this tests just a bit of header sanity: for each header
>> "FOO.h", test whether
>>
>>         #include "qemu/osdep.h"
>>         #include "FOO.h"
>>         #include "FOO.h"
>>
>> compiles.  A large number of headers don't pass this test, by design
>> or by accident.  These are all excluded for now.  Excluded headers
>> contain a comment
>>
>>     /* FIXME Does not pass make check-headers, yet! */
>>
>> Many headers fail the test only with CONFIG_WIN32.  These contain a
>> comment
>>
>>     /* FIXME Does not pass make check-headers with CONFIG_WIN32, yet! */
>>
>> Add make target check-excluded-headers to help with examining how they
>> fail.
>>
>> These tests work only in a git tree, with git installed.
>>
>> Signed-off-by: Markus Armbruster <address@hidden>
>
>>  disas/libvixl/vixl/a64/assembler-a64.h    |  2 ++
>>  disas/libvixl/vixl/a64/constants-a64.h    |  2 ++
>>  disas/libvixl/vixl/a64/cpu-a64.h          |  2 ++
>>  disas/libvixl/vixl/a64/decoder-a64.h      |  2 ++
>>  disas/libvixl/vixl/a64/disasm-a64.h       |  2 ++
>>  disas/libvixl/vixl/a64/instructions-a64.h |  2 ++
>>  disas/libvixl/vixl/code-buffer.h          |  2 ++
>>  disas/libvixl/vixl/compiler-intrinsics.h  |  2 ++
>>  disas/libvixl/vixl/globals.h              |  2 ++
>>  disas/libvixl/vixl/invalset.h             |  2 ++
>>  disas/libvixl/vixl/platform.h             |  2 ++
>>  disas/libvixl/vixl/utils.h                |  2 ++
>
> This is third-party code. We're not going to change it, so
> we should avoid scanning it rather than adding tags which
> will get lost next time we do an update to a new upstream
> version...

I can revive v1's blacklist for this directory.  Any others?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]