All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sami Tolvanen <samitolvanen@google.com>
To: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: clang-built-linux@googlegroups.com, keescook@chromium.org,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
	masahiroy@kernel.org, michal.lkml@markovi.net, nathan@kernel.org,
	ndesaulniers@google.com, yj.chiang@mediatek.com
Subject: Re: [PATCH v3 1/2] Kbuild: lto: add CONFIG_MAKE_VERSION
Date: Wed, 7 Jul 2021 10:02:24 -0700	[thread overview]
Message-ID: <CABCJKufWcp6Hx=8btz6pDNcKvQ21n4BSPZ7cp1Tzhxt0+pQOmw@mail.gmail.com> (raw)
In-Reply-To: <20210706090607.19421-1-lecopzer.chen@mediatek.com>

On Tue, Jul 6, 2021 at 2:06 AM Lecopzer Chen <lecopzer.chen@mediatek.com> wrote:
>
> > On Sun, Jul 4, 2021 at 7:03 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
> > >
> > > On Fri, Jul 2, 2021 at 12:29 PM Lecopzer Chen
> > > <lecopzer.chen@mediatek.com> wrote:
> > > >
> > > > To check the GNU make version. Used by the LTO Kconfig.
> > > >
> > > > LTO with MODVERSIONS will fail in generating correct CRC because
> > > > the makefile rule doesn't work for make with version 3.8X.[1]
> > > >
> > > > Thus we need to check make version during selecting on LTO Kconfig.
> > > > Add CONFIG_MAKE_VERSION which means MAKE_VERSION in canonical digits
> > > > for arithmetic comparisons.
> > > >
> > > > [1] https://lore.kernel.org/lkml/20210616080252.32046-1-lecopzer.chen@mediatek.com/
> > > > Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
> > > > ---
> > >
> > >
> > > NACK.
> > >
> > > "Let's add MAKE_VERSION >= 40200 restriction
> > > just because I cannot write correct code that
> > > works for older Make" is a horrible idea.
> > >
> > > Also, Kconfig is supposed to check the compiler
> > > (or toolchains) capability, not host tool versions.
> >
> > I feel like requiring a Make that's half a decade old for a feature
> > that also requires a toolchain released last October ago isn't
> > entirely unreasonable.
> >
> > That being said, if Masahiro prefers not to rely on the wildcard
> > function's behavior here, which is a reasonable request, we could
> > simply use the shell to test for the file's existence:
> >
> > diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> > index 34d257653fb4..c6bd62f518ff 100644
> > --- a/scripts/Makefile.build
> > +++ b/scripts/Makefile.build
> > @@ -388,7 +388,7 @@ ifeq ($(CONFIG_LTO_CLANG) $(CONFIG_MODVERSIONS),y y)
> >        cmd_update_lto_symversions =                                     \
> >         rm -f $@.symversions                                            \
> >         $(foreach n, $(filter-out FORCE,$^),                            \
> > -               $(if $(wildcard $(n).symversions),                      \
> > +               $(if $(shell test -s $(n).symversions && echo y),       \
> >                         ; cat $(n).symversions >> $@.symversions))
> >  else
> >        cmd_update_lto_symversions = echo >/dev/null
> >
> > This is not quite as efficient as using wildcard, but should work with
> > older Make versions too. Thoughts?
> >
>
>
> I've tested this in both make-4.3 and 3.81, and the CRC is correct.
> But I'm not sure if anyone would have the "arg list too long" issue.
>
> Tested-by: Lecopzer Chen <lecopzer.chen@mediatek.com>

Thank you for testing. This should produce a command identical to the
wildcard version (with newer Make versions), so that shouldn't be an
issue. If nobody objects to this approach, would you mind putting this
into a proper patch and sending it as v4?

Sami

  reply	other threads:[~2021-07-07 17:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-02  3:29 [PATCH v3 0/2] Kbuild: lto: add make version checking for MODVERSIONS Lecopzer Chen
2021-07-02  3:29 ` [PATCH v3 1/2] Kbuild: lto: add CONFIG_MAKE_VERSION Lecopzer Chen
2021-07-04  0:15   ` Nathan Chancellor
2021-07-05  2:02   ` Masahiro Yamada
2021-07-05 17:59     ` Sami Tolvanen
2021-07-06  9:06       ` Lecopzer Chen
2021-07-07 17:02         ` Sami Tolvanen [this message]
2021-07-09  8:25           ` Lecopzer Chen
2021-07-02  3:29 ` [PATCH v3 2/2] Kbuild: lto: add make version checking Lecopzer Chen
2021-07-04  0:16   ` Nathan Chancellor
2021-07-05  2:04   ` 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='CABCJKufWcp6Hx=8btz6pDNcKvQ21n4BSPZ7cp1Tzhxt0+pQOmw@mail.gmail.com' \
    --to=samitolvanen@google.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=keescook@chromium.org \
    --cc=lecopzer.chen@mediatek.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=yj.chiang@mediatek.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.