Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 14 Jan 2021 08:57:11 -0600
From:   Josh Poimboeuf <jpoimboe@redhat.com>
To:     Bernd Petrovitsch <bernd@petrovitsch.priv.at>
Cc:     Masahiro Yamada <masahiroy@kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Toolchain-dependent config options
Message-ID: <20210114145711.3yfx2x6snjij3bxl@treble>
References: <20210113222112.ej4rrd5xw2pwegvw@treble>
 <CAK7LNASbYiZ+UVTmUwRDGMMHQXO-oE-3a4RxbEqX+=dCG2U6dw@mail.gmail.com>
 <53fccf6d59938e94f71a823d704e26903b98fb7d.camel@petrovitsch.priv.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <53fccf6d59938e94f71a823d704e26903b98fb7d.camel@petrovitsch.priv.at>
Precedence: bulk

On Thu, Jan 14, 2021 at 12:55:26PM +0100, Bernd Petrovitsch wrote:
> Hi all!
> 
> On Thu, 2021-01-14 at 13:56 +0900, Masahiro Yamada wrote:
> > On Thu, Jan 14, 2021 at 7:21 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> [...]
> > > If I copy a config with CONFIG_GCC_PLUGINS to another system which
> > > doesn't have the gcc-plugin-devel package, it gets silently disabled by
> > > "make olddefconfig".
> > > 
> > > I've seen multiple cases lately where this is causing confusion.  I
> > > suspect the problem is getting worse with recent added support for a
> > > variety of toolchains and toolchain-dependent features.
> > > 
> > > Would it be possible to have an error (or at least a warning) in this
> > > case?
> > > 
> > > For example, a "depends-error" which triggers an error if its failure
> > > would disable a feature?
> [...]
> > We disable any feature that is unsupported by the compiler in use.
> > 
> > Conventionally, we did that in the top Makefile
> > by using $(call cc-option, ) macro or by running some scripts.
> > 
> > Recently, we are moving such compiler tests to the Kconfig stage.
> > 
> > Anyway, we disable unsupported features so any combination
> > of CONFIG options builds successfully.
> > This will ease randconfg and allmodconfig tests.
> 
> For options of $CC, that makes sense since there are different
> compilers and lots of versions of them out there.
> 
> > A lot of people and CI systems are running allmodconfig tests
> > for various architectures and toolchains.
> 
> Isn't some kind of defying (or more killing) the usefulness
> of regression compile runs if one does `make allmodconfig`
> and some (lots?) of stuff gets automatically configured
> out just because some
> -dev(|el) package is missing?

Right, it sort of defeats the purpose of CI if new toolchain-dependent
features never get tested.  There needs to be some way to alert the user
they're not testing everything, despite "allyesconfig".

I suppose such config options can stop using this new "depends on
some_script" feature and just do it the old-fashioned way with an
$(error) in the makefile.

-- 
Josh