On Thu, 06 Jun 2019, <yamada.masahiro@xxxxxxxxxxxxx> wrote: > Hi Jani, > >> -----Original Message----- >> From: Jani Nikula [mailto:jani.nikula@xxxxxxxxx] >> Sent: Thursday, June 06, 2019 4:25 PM >> To: Yamada, Masahiro/山田 真弘 <yamada.masahiro@xxxxxxxxxxxxx>; >> intel-gfx@xxxxxxxxxxxxxxxxxxxxx >> Cc: lkp@xxxxxxxxx; chris@xxxxxxxxxxxxxxxxxx; sam@xxxxxxxxxxxx; >> masahiroy@xxxxxxxxxx >> Subject: RE: [PATCH] drm/i915: rename header test build commands to avoid >> conflicts >> >> On Thu, 06 Jun 2019, <yamada.masahiro@xxxxxxxxxxxxx> wrote: >> > Hi, >> > >> >> -----Original Message----- >> >> From: Jani Nikula [mailto:jani.nikula@xxxxxxxxx] >> >> Sent: Wednesday, June 05, 2019 10:22 PM >> >> To: intel-gfx@xxxxxxxxxxxxxxxxxxxxx >> >> Cc: jani.nikula@xxxxxxxxx; kbuild test robot <lkp@xxxxxxxxx>; Chris >> Wilson >> >> <chris@xxxxxxxxxxxxxxxxxx>; Yamada, Masahiro/山田 真弘 >> >> <yamada.masahiro@xxxxxxxxxxxxx>; Sam Ravnborg <sam@xxxxxxxxxxxx> >> >> 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/?i=20190604124248.5564-1-jani.nikula@xxxxxxxxx >> >> >> >> Reported-by: kbuild test robot <lkp@xxxxxxxxx> >> >> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> >> >> Cc: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx> >> >> Cc: Sam Ravnborg <sam@xxxxxxxxxxxx> >> >> Signed-off-by: Jani Nikula <jani.nikula@xxxxxxxxx> >> >> --- >> > >> > >> > 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 > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx