Re: Toolchain-dependent config options
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 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
Re: Toolchain-dependent config options
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 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 : be...@petrovitsch.priv.at There is no cloud, just other people computers. - FSFE LUGA : http://www.luga.at
Re: Toolchain-dependent config options
On Thu, Jan 14, 2021 at 7:21 AM Josh Poimboeuf 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
Toolchain-dependent config options
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