>>> On 29.01.15 at 12:54, <tamas.leng...@zentific.com> wrote: > On Thu, Jan 22, 2015 at 4:34 PM, Tamas K Lengyel > <tamas.leng...@zentific.com> wrote: >> On Thu, Jan 22, 2015 at 4:00 PM, Jan Beulich <jbeul...@suse.com> wrote: >>>>>> On 18.01.15 at 16:17, <tamas.leng...@zentific.com> wrote: >>>> --- a/xen/include/Makefile >>>> +++ b/xen/include/Makefile >>>> @@ -90,7 +90,7 @@ ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH)) >>>> >>>> all: headers.chk >>>> >>>> -headers.chk: $(filter-out public/arch-% public/%ctl.h public/xsm/% >>>> public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) $(public-y)) >>>> Makefile >>>> +headers.chk: $(filter-out public/arch-% public/%ctl.h public/mem_event.h >>>> public/xsm/% public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) >>>> $(public-y)) Makefile >>> >>> I think you should finally break this already too long line. But of course >>> first of all you'll want to explain why the addition is necessary/correct. >>> The mere fact that this now becomes a tools-only interface isn't >>> enough imo - some of the other headers excluded here would better >>> undergo the checking too, just that first they would need cleaning up. >> >> I have to revisit what is actually going on here, I believe I had to >> add this to get Xen to build. On a second look not sure why that was. > > So I double checked and the addition here is correct, without > excluding the header, the compilation fails at #if !defined(__XEN__) > && !defined(__XEN_TOOLS__) in mem_event.h.
Hardly at that line. I'm afraid I won't be convinced without you explaining what fails why, and why that can't be dealt with. > So I'll break the line but > cleaning up/checking the other headers IMHO is out of scope for this > series. Of course, no-one asked you to do this (and even less so in this series). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
