public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
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

  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