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;
MIME-Version: 1.0
References: <20210113222112.ej4rrd5xw2pwegvw@treble>
In-Reply-To: <20210113222112.ej4rrd5xw2pwegvw@treble>
From:   Masahiro Yamada <masahiroy@kernel.org>
Date:   Thu, 14 Jan 2021 13:56:02 +0900
Message-ID: <CAK7LNASbYiZ+UVTmUwRDGMMHQXO-oE-3a4RxbEqX+=dCG2U6dw@mail.gmail.com>
Subject: Re: Toolchain-dependent config options
To:     Josh Poimboeuf <jpoimboe@redhat.com>
Cc:     Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Jan 14, 2021 at 7:21 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> Hi Masahiro,
>
> 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?
>
> --
> Josh
>


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.

A lot of people and CI systems are running allmodconfig tests
for various architectures and toolchains.

Introducing the build breakage is annoying.


-- 
Best Regards
Masahiro Yamada