From: Jani Nikula <jani.nikula@intel.com>
To: yamada.masahiro@socionext.com, intel-gfx@lists.freedesktop.org
Cc: masahiroy@kernel.org, sam@ravnborg.org
Subject: Re: [PATCH] drm/i915: rename header test build commands to avoid conflicts
Date: Thu, 06 Jun 2019 11:00:11 +0300 [thread overview]
Message-ID: <875zpj2lf8.fsf@intel.com> (raw)
In-Reply-To: <a1ee368a8fe343788163a85b61b565e5@SOC-EX01V.e01.socionext.com>
On Thu, 06 Jun 2019, <yamada.masahiro@socionext.com> wrote:
> Hi Jani,
>
>> -----Original Message-----
>> From: Jani Nikula [mailto:jani.nikula@intel.com]
>> Sent: Thursday, June 06, 2019 4:25 PM
>> To: Yamada, Masahiro/山田 真弘 <yamada.masahiro@socionext.com>;
>> intel-gfx@lists.freedesktop.org
>> Cc: lkp@intel.com; chris@chris-wilson.co.uk; sam@ravnborg.org;
>> masahiroy@kernel.org
>> Subject: RE: [PATCH] drm/i915: rename header test build commands to avoid
>> conflicts
>>
>> On Thu, 06 Jun 2019, <yamada.masahiro@socionext.com> wrote:
>> > Hi,
>> >
>> >> -----Original Message-----
>> >> From: Jani Nikula [mailto:jani.nikula@intel.com]
>> >> Sent: Wednesday, June 05, 2019 10:22 PM
>> >> To: intel-gfx@lists.freedesktop.org
>> >> Cc: jani.nikula@intel.com; kbuild test robot <lkp@intel.com>; Chris
>> Wilson
>> >> <chris@chris-wilson.co.uk>; Yamada, Masahiro/山田 真弘
>> >> <yamada.masahiro@socionext.com>; Sam Ravnborg <sam@ravnborg.org>
>> >> 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@intel.com
>> >>
>> >> Reported-by: kbuild test robot <lkp@intel.com>
>> >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> >> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
>> >> Cc: Sam Ravnborg <sam@ravnborg.org>
>> >> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>> >> ---
>> >
>> >
>> > 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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-06-06 7:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-05 13:21 [PATCH] drm/i915: rename header test build commands to avoid conflicts Jani Nikula
2019-06-05 13:35 ` Sam Ravnborg
2019-06-05 14:53 ` ✓ Fi.CI.BAT: success for " Patchwork
2019-06-06 3:04 ` [PATCH] " yamada.masahiro
2019-06-06 7:24 ` Jani Nikula
2019-06-06 7:32 ` yamada.masahiro
2019-06-06 8:00 ` Jani Nikula [this message]
2019-06-06 12:03 ` Masahiro Yamada
2019-06-06 12:16 ` Jani Nikula
2019-06-07 1:50 ` ✓ Fi.CI.IGT: success for " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875zpj2lf8.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=masahiroy@kernel.org \
--cc=sam@ravnborg.org \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox