Received-SPF: pass (google.com: domain of linux-kernel+bounces-86099-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Thu, 29 Feb 2024 12:47:39 +0900
From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv2] kconfig: add some Kconfig env variables to make help
Message-ID: <20240229034739.GN11972@google.com>
References: <20240222031801.GG11472@google.com>
 <20240222032559.496127-1-senozhatsky@chromium.org>
 <CAK7LNARo4L6qxoqRU-0dgABarukJKAaZpCRtfA3MyUHhSuDQxQ@mail.gmail.com>
 <20240222051621.GH11472@google.com>
 <20240228045652.GH11972@google.com>
 <CAK7LNAQ8OyNMeGzVoTRg-sHDZ4YK0EKY_eEWNepekaibO_ZKwg@mail.gmail.com>
 <20240229021010.GM11972@google.com>
 <CAK7LNASujf8m4PpMyoCC1cTN_YGeG1HVaOR+3pZx5=3OJp=85A@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAK7LNASujf8m4PpMyoCC1cTN_YGeG1HVaOR+3pZx5=3OJp=85A@mail.gmail.com>

On (24/02/29 12:36), Masahiro Yamada wrote:
> > On (24/02/29 11:03), Masahiro Yamada wrote:
> > > > > > > +++ b/scripts/kconfig/Makefile
[..]
> > > > > > > +       @echo  ''
> > > > > > > +       @echo  'Configuration environment variables:'
> > > > > > > +       @echo  '  KCONFIG_WERROR                 - Turn some Kconfig warnings into error conditions'
> > > > > > > +       @echo  '  KCONFIG_WARN_UNKNOWN_SYMBOLS   - Make Kconfig warn about all unrecognized config symbols'
> > > > > > >
> > > > > > >  # ===========================================================================
> > > > > > >  # object files used by all kconfig flavours
> > > > > > > --
> > > > > > > 2.44.0.rc0.258.g7320e95886-goog
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > Why only two, while Kconfig supports more env variables?
> > > > >
> > > > > Right.  I wanted to add only those that we use (and familiar with) for
> > > > > starters.  I'm not familiar with things like KCONFIG_PROBABILITY, for
> > > > > instance, and not sure how to document it (its Documentation/kbuild/kconfig.rst
> > > > > description is pretty lengthy).
> > > >
> > > > Masahiro, any opinion?
> > >
> > >
> > > I do not need this patch.
> >
> > Do you agree that putting kconfig env knobs into help makes sense
> > in general?  Especially those add valuable sanity checks.
>
> I cannot accept the attitude:

This is entirely wrong interpretation.

>   "I am interested only in these. I do not care about the rest,

It's "I *do NOT know* what the rest do".  I cannot document something
that I have no knowledge of, can I?  So as a reasonable start I added
only those that I'm familiar with (and I have explicitly stated that
in previous emails), and I disagree with the "bad attitude" label.

> This should be all or nothing.
>
> I do not think all the env variables can be summarized
> to fit in help.

So the rational for that was that people run "make help" and find
out about new build targets, for instance, but there is no way for
people to find out about new Kconfig features (and yes, we are talking
"new features" here) that are controlled by env variables.  We need
to do something about it, don't you agree?