lkml.org 
[lkml]   [2021]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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 <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

    \
     
     \ /
      Last update: 2021-01-14 16:01    [W:5.076 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site