| Message ID | 1535968916-9159-1-git-send-email-yamada.masahiro@socionext.com |
|---|---|
| Headers | show |
| Series | kbuild: support syncing .config non-interactively and record ARCH in spec file | expand |
On 9/3/18 6:01 AM, Masahiro Yamada wrote: > This work was prompted by the criticism about the recent Kconfig change: > https://lkml.org/lkml/2018/6/27/254 > > I may not fully understand his concern, though. I don't think you do. Here's the use case for us and, I expect, most distro kernel maintainers out there. We build kernels on 8 architectures, with 3 or more configs for each architecture. Each product release uses a different build environment. Between SLE and openSUSE we have 6 build environments at the moment. Our update process for configs is to run a script that adds the change to every affected config and then run a script that does a 'make oldconfig' on every architecture/config combination to sync them up and ensure options that may have been enabled by the change are synced up. Those changes are also automatically propagated to other configs. The config updates can be done on pretty much any linux system capable of building a kernel. This is a process that has worked for us for at least 15 years. It doesn't now with the GCC_VERSION changes. Today, I went to do a simple config change: disable an option on every arch/config combination for a single branch (that wasn't the one that matched the build environment of the running system) and instead of it running more or less silently as it has for years, it wanted to change all the compiler options. Of course, those changes shouldn't be pushed to the repository because they'll be wrong for the build environment. In this simple example it was easy to just modify the option in-place, but it would've been painful if I was enabling an option that guarded other new options instead. Lastly, we fail our builds if there are unresolved config options. A build that silently ignored them and accepted defaults isn't something we'd use. Otherwise, we could start our builds with yes '' | make oldconfig and be done with it. Requiring the config to be generated using the same environment that will ultimately build the kernel is a huge usability regression for us and, I would assume, others. -Jeff -- Jeff Mahoney SUSE Labs
This work was prompted by the criticism about the recent Kconfig change: https://lkml.org/lkml/2018/6/27/254 I may not fully understand his concern, though. Masahiro Yamada (3): kconfig: support an environment variable for non-interactive syncconfig kbuild: rpm-pkg: hard-code ARCH in RPM SPEC file kbuild: rpm-pkg: set KCONFIG_NONINTERACTIVE_UPDATE Documentation/kbuild/kconfig.txt | 6 ++++++ scripts/kconfig/conf.c | 5 +++++ scripts/package/mkspec | 23 +++++++++++++---------- 3 files changed, 24 insertions(+), 10 deletions(-) -- 2.7.4