[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK7LNARa3WrRp5vmX5M3tTkS-jdno-vFe8WLPXjF8+hHxVUmFA@mail.gmail.com>
Date: Fri, 29 Dec 2023 22:41:54 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: Patrick Georgi <pgeorgi@...gle.com>, linux-kbuild@...r.kernel.org,
linux-kernel@...r.kernel.org, Stefan Reinauer <reinauer@...gle.com>
Subject: Re: [PATCH] kconfig: WERROR unmet symbol dependency
On Fri, Dec 22, 2023 at 11:57 AM Sergey Senozhatsky
<senozhatsky@...omium.org> wrote:
>
> On (23/12/01 00:42), Masahiro Yamada wrote:
> > On Wed, Nov 29, 2023 at 1:13 PM Sergey Senozhatsky
> > <senozhatsky@...omium.org> wrote:
> > >
> > > On (23/11/28 23:19), Masahiro Yamada wrote:
> > >
> > > [..]
> > >
> > > > KCONFIG_WERROR is meant to turn all warnings
> > > > to errors.
> > > > I do not see getenv("KCONFIG_WERROR")
> > > > sprinkled everywhere in Kconfig.
> > > > One more thing, you cannot directly exit(1)
> > > > from sym_calc_value().
> > >
> > > We do exit(1) for KCONFIG_WARN_UNKNOWN_SYMBOLS in conf_read().
> > >
> > > I can introduce two new helpers that will tell if confdata.c and symbol.c
> > > triggered any warnings and if KCONFIG_WERROR is set. And then different
> > > code paths can call them and handle exit gracefully, depending on the
> > > context (ncurses, menu, etc.).
> > >
> > > Something like this
> >
> >
> > I do not want to patch warnings one by one.
> >
> >
> > I will take some time to think about it.
>
> Gentle ping on this.
>
> We are not concerned with every possible warning at the moment, however,
> we do want the critical ones from CI and (semi)automated continuous uprev
> PoV to be covered by WERROR. We do experience real life problems with
> "missing direct dependency" not being a terminal condition under WERROR.
Applied to linux-kbuild.
Thanks.
--
Best Regards
Masahiro Yamada
Powered by blists - more mailing lists