7646 2015-04-22 14:39:37 +0000 KBUILD_DEFCONFIG does not work if config file is created as a result of patch to be applied 2020-08-28 20:09:07 +0000 1 1 6 Yocto Project Subprojects Kernel kernel-configuration 1.8 Galileo x86 RESOLVED FIXED Medium enhancement 4.99 1 imran.zaman bruce.ashfield randy.macleod sgw stephano yp.kernel.watcher yp.watcher --- --- Don't know oldest_to_newest 50474 0 imran.zaman 2015-04-22 14:39:37 +0000 1- In kernel bbappend file, set KBUILD_DEFCONFIG="${S}/arch/x86/configs/quark_defconfig" A patch creates quark_defconfig file.. 2- SRC_URI += "file://patch-config-which-creates-quark-defconfig" Since the kernel_metadata runs before kernel_patch, then it fails with following error.. Log data follows: | DEBUG: Executing shell function do_kernel_metadata | ERROR: A KBUILD_DECONFIG '/tmp-glibc/work-shared/quark/kernel-source/arch/x86/configs/quark_defconfig' was specified, but not present in the source tree | WARNING: exit code 1 from a shell command. 50475 1 bruce.ashfield 2015-04-22 14:49:17 +0000 I didn't even really want to add KBUILD_DEFCONFIG in the first place, it is for fully integrated defconfig and non-yocto style builds. In this case, if you are modifying a base configuration like this, use fragments. The meta data generation must run before patching, so there's no way that you can have both supported. We can perhaps trap this at build time and report the issue, and get it into the documentation. But this isn't something that really can be supported .. we have to draw the line somewhere. 50476 2 bruce.ashfield 2015-04-22 14:53:09 +0000 (In reply to comment #1) > I didn't even really want to add KBUILD_DEFCONFIG in the first place, it > is for fully integrated defconfig and non-yocto style builds. > > In this case, if you are modifying a base configuration like this, > use fragments. > > The meta data generation must run before patching, so there's no > way that you can have both supported. > > We can perhaps trap this at build time and report the issue, and get > it into the documentation. But this isn't something that really can > be supported .. we have to draw the line somewhere. I should say, that in this case, you can arrange for the defconfig to be copied into WORKDIR and used, by adding your own tasks before do_configure runs. Or simply carrying the defconfig as a complete file and having the fetcher copy it, versus a patch into the kernel. As long as it ends up called 'defconfig' in WORKDIR, it will be mixed into the configuration process. 50751 3 bruce.ashfield 2015-05-04 15:13:48 +0000 FYI: This is something we can address with streamlined kernel configuration tasks, which will be part of 1.9. 60243 4 bruce.ashfield 2016-03-21 23:25:54 +0000 Moving to 2.2. No one is asking about this explicitly, so I'm de-cluttering M4 to work on critical issues. If there's a call for this, we can back port the change. 66504 5 bruce.ashfield 2016-09-22 16:13:09 +0000 I have this prototyped. I'll see if it can squeeze into m4. Otherwise, I'll bump it to the next release. 69676 6 bruce.ashfield 2017-01-10 20:38:47 +0000 Moving to M3. 86760 7 randy.macleod 2020-03-19 15:05:09 +0000 Bruce, Is this still needed? 88061 8 bruce.ashfield 2020-08-28 20:09:07 +0000 The meta-data phase has been split in two. Configuration gathering runs after patching, so what this bug is looking for .. is now possible.