On Thu, 06 Jun 2019, <[email protected]> wrote:
> Hi Jani,
>
>> -----Original Message-----
>> From: Jani Nikula [mailto:[email protected]]
>> Sent: Thursday, June 06, 2019 4:25 PM
>> To: Yamada, Masahiro/山田 真弘 <[email protected]>;
>> [email protected]
>> Cc: [email protected]; [email protected]; [email protected];
>> [email protected]
>> Subject: RE: [PATCH] drm/i915: rename header test build commands to avoid
>> conflicts
>> 
>> On Thu, 06 Jun 2019, <[email protected]> wrote:
>> > Hi,
>> >
>> >> -----Original Message-----
>> >> From: Jani Nikula [mailto:[email protected]]
>> >> Sent: Wednesday, June 05, 2019 10:22 PM
>> >> To: [email protected]
>> >> Cc: [email protected]; kbuild test robot <[email protected]>; Chris
>> Wilson
>> >> <[email protected]>; Yamada, Masahiro/山田 真弘
>> >> <[email protected]>; Sam Ravnborg <[email protected]>
>> >> Subject: [PATCH] drm/i915: rename header test build commands to avoid
>> >> conflicts
>> >>
>> >> We have a local hack to test if headers are self-contained, while
>> >> upstreaming a proper generic solution in kbuild [1]. Now that both have
>> >> found themselves in linux-next, the identical cmd_header_test build
>> >> commands conflict, leading to errors such as:
>> >>
>> >> >> drivers/gpu/drm/i915/header_test_intel_audio.c:1:10: fatal error:
>> >> >> drivers/gpu/drm/i915/intel_audio.h: No such file or directory
>> >>     #include "drivers/gpu/drm/i915/intel_audio.h"
>> >>        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >>
>> >> Rename the i915 local build command until the proper kbuild solution
>> >> finds its way to Linus' master and gets backported to our tree, and we
>> >> can finally switch over.
>> >>
>> >> Note that since the kbuild header test requires CONFIG_HEADER_TEST=y,
>> >> and our hack requires our debug option CONFIG_DRM_I915_WERROR=y, this
>> is
>> >> likely hit only by build test bots.
>> >>
>> >> [1] http://marc.info/[email protected]
>> >>
>> >> Reported-by: kbuild test robot <[email protected]>
>> >> Cc: Chris Wilson <[email protected]>
>> >> Cc: Masahiro Yamada <[email protected]>
>> >> Cc: Sam Ravnborg <[email protected]>
>> >> Signed-off-by: Jani Nikula <[email protected]>
>> >> ---
>> >
>> >
>> > This is not really queued up yet.
>> >
>> > So, we can squash fix-up to avoid 0day bot report.
>> 
>> Except I don't think your linux-kbuild.git baseline has the files you're
>> patching below. The problem only exists at the merge of our trees,
>> currently only linux-next, and not "for real" until the v5.3 merge
>> window. So I think the sane option is to patch it up in our tree.
>
>
> I do not understand.
>
> This is a _real_ problem since
>   drivers/gpu/drm/i915/Makefile.header-test
> exists in Linus' tree.
>
>
> The 0-day bot reported the build error against my tree,
> so I must fix it in my tree.
>
>
>> I want to use our local hack until we can get the backmerge from
>> v5.3-rc1, because it's 7-8 weeks away, and I want to retain our own
>> pre-merge build test coverage until then rather than relying on 0day
>> post-merge testing on linux-next.
>
>
> Neither of my patches breaks your test coverage.
> CONFIG_DRM_I915_WERROR still works in linux-next too.
>
> What am I missing?

Apologies, my bad. I completely failed to realize Makefile.header-test
already hit Linus' tree. *facepalm*

You're totally right, it needs to be fixed in your tree. For that, I
think the best option is your fixup patch #2.

(Now that header-test-y is behind CONFIG_HEADER_TEST=y, I don't think
this really requires CONFIG_DRM_I915_WERROR=y anymore, but no big deal
either way.)

We do have two more instances in -next that are not in Linus' tree, so
we'll need to fix those locally anyway. Part of the confusion.


BR,
Jani.



>
>
>
> Thanks.
>
> Masahiro Yamada
>
> _______________________________________________
> Intel-gfx mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to