On Tue, Jun 30, 2009 at 2:41 AM, Randy Dunlap <randy.dunlap@xxxxxxxxxx> wrote: > > On Mon, 29 Jun 2009 15:26:51 +1000 John Williams wrote: > > > Is there a mechanism to override or update a CONFIG_ value during the > > make process? > > > > In the MicroBlaze architecture we have a highly configurable CPU - > > various ALU options can be enabled or disabled at will during the > > hardware build phase. We have several Kconfig options that must match > > this, and which are used to generate the appropriate CFLAGS during > > kernel build. e.g. > > > > CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div > > CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift > > CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR) += -mxl-pattern-compare > > > [snip] > > > Thus, returning to the question - is there a sane way that we can > > override or force the relevant CONFIG_ values, from within the > > Makefile itself? Or, must we resort to a script, and do it as a > > preprocessing step? Is there a reasonable way to still integrate this > > into the kernel build phase? > > I thought that it was possible to override CONFIG_ symbols on the > "make" command line, and my limited testing confirms that. > > E.g.: > > make ARCH=x86_64 O=xx64 defconfig > make CONFIG_HEADERS_CHECK=y CONFIG_BUILD_DOCSRC=y ARCH=x86_64 O=xx64 -j4 all > > does cause BUILD_DOCSRC builds to happen although BUILD_DOCSRC is not set in > the defconfig file. (I set HEADERS_CHECK=y first since BUILD_DOCSRC depends > on HEADERS_CHECK.) Sure, this works. What I'm wondering is if there is a valid way we can do the override *inside* the kbuild process itself, ie in our arch Makefile we could parse the DTS file and automagically update the relevent CONFIG_* to match the DTS file. Thoughts from any kbuild experts? I can go hack something up but would prefer to have some non-zero probability of future merge acceptance. Thanks, John -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
