linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masahiro Yamada <masahiroy@kernel.org>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH RFC] Kbuild: Makefile: warn if auto.conf is obsolete
Date: Fri, 1 May 2020 12:27:19 +0900	[thread overview]
Message-ID: <CAK7LNARA2+S5mjzRucvdJ-zQo6UEAuNi9npJvJB+JcVgh+d_3w@mail.gmail.com> (raw)
In-Reply-To: <20200430212511.2115ed98@coco.lan>

On Fri, May 1, 2020 at 4:25 AM Mauro Carvalho Chehab
<mchehab+huawei@kernel.org> wrote:
>
> A new behavior on more recent kernels require to always call
> "make modules_prepare" after *any* Kconfig changes.


Again, this is the behavior since 2004.

This commit:
https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=95065ad3fa787c417008a36d3a5d9a3bab17ab98


Shrug if you complain about what has been stable
more than 15 years.


> This is not what a poor mortal would be expecting on a building
> system, as it should, IMHO, be able to detect and auto-run
> whatever is needed to use the newer setup.

No. External module builds should never ever attempt to update
in-tree files.

This is because the build environment for external modules
is usually located in /lib/modules/$(uname -r)/build/,
which is read-only.


A number of upstream developers (ab)use
M= to compile test individual directories,
despite the fact Kbuild supports
the single target 'make drivers/staging/media/stomisp/'



You need to cope with this conflicting comment line:
https://github.com/masahir0y/linux/blob/v5.6/Makefile#L681
since you care if auto.conf is up-to-date.





> Yet, while this is not solved, let's at least stop the build
> and produce a warning, to notify the user about that.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
>
> I would still prefer to call "make modules_prepare" directly,
> on such cases, but just calling "make -C . modules_prepare" doesn't
> work. So, the next best thing would be to at least print a message
> and don't try to do a build with a broken auto.conf file.
>
>  Makefile | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 70def4907036..492ee2396ab9 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1632,6 +1632,11 @@ $(objtree)/Module.symvers:
>  build-dirs := $(KBUILD_EXTMOD)
>  PHONY += modules
>  modules: descend $(objtree)/Module.symvers
> +       @if [ $(KCONFIG_CONFIG) -nt include/config/auto.conf ]; then \
> +               echo "  WARNING: $(KCONFIG_CONFIG) was modified. Need to run:"; \
> +               echo "           $(MAKE) modules_prepare"; \
> +               exit -1; \
> +       fi
>         $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
>
>  PHONY += modules_install








--
Best Regards
Masahiro Yamada

  reply	other threads:[~2020-05-01  3:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-30 11:17 bug: Kbuild seems to require "make prepare-objtool" in order to use (some) new config vars Mauro Carvalho Chehab
2020-04-30 13:51 ` Masahiro Yamada
2020-04-30 16:49   ` Mauro Carvalho Chehab
2020-04-30 17:20     ` Masahiro Yamada
2020-04-30 19:10       ` Mauro Carvalho Chehab
2020-04-30 19:25         ` [PATCH RFC] Kbuild: Makefile: warn if auto.conf is obsolete Mauro Carvalho Chehab
2020-05-01  3:27           ` Masahiro Yamada [this message]
2020-05-01  2:31         ` bug: Kbuild seems to require "make prepare-objtool" in order to use (some) new config vars Masahiro Yamada

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=CAK7LNARA2+S5mjzRucvdJ-zQo6UEAuNi9npJvJB+JcVgh+d_3w@mail.gmail.com \
    --to=masahiroy@kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab+huawei@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).