| Summary: | KBUILD_DEFCONFIG does not work if config file is created as a result of patch to be applied | ||
|---|---|---|---|
| Product: | [Yocto Project Subprojects] Kernel | Reporter: | Imran Zaman <imran.zaman> |
| Component: | kernel-configuration | Assignee: | Bruce Ashfield <bruce.ashfield> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Medium | CC: | randy.macleod, sgw, stephano, yp.kernel.watcher, yp.watcher |
| Version: | 1.8 | ||
| Target Milestone: | 4.99 | ||
| Hardware: | Galileo | ||
| OS: | x86 | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
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. (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. FYI: This is something we can address with streamlined kernel configuration tasks, which will be part of 1.9. 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. I have this prototyped. I'll see if it can squeeze into m4. Otherwise, I'll bump it to the next release. Moving to M3. Bruce, Is this still needed? The meta-data phase has been split in two. Configuration gathering runs after patching, so what this bug is looking for .. is now possible. |
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.