Toolchain-dependent config options

Toolchain-dependent config options

[Josh Poimboeuf]

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

Re: Toolchain-dependent config options

[Masahiro Yamada]

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

Re: Toolchain-dependent config options

[Bernd Petrovitsch]

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?

Aren't there some kernel-build meta packages for various
distributions out there that pull all necessary in?

> Introducing the build breakage is annoying.

Yes, update/install the necessary package to fix it.

MfG,
	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
There is no cloud, just other people computers. - FSFE
                     LUGA : http://www.luga.at

Re: Toolchain-dependent config options

[Josh Poimboeuf]

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