On Sun, Nov 20, 2016 at 08:20:51PM +0000, ron minnich wrote:
[...] There's also no fundamental reason for using the name .config other than tradition. We could, for example, create build/vendor/mainboard/config and use that.
One minor concern with that placement is that I enjoy the ability to nuke a partial or corrupted builds my doing 'rm -rf coreboot/x230', so having the config file stored in a generated directory would be problematic.
However, it would be nice to remember the $(obj) and $(DOTCONFIG) variables when oldconfig is run in an external build. kbuild generates a Makefile in the external directory with its equivilant of those variables preset so that you can run 'make' in the output directory and have it do the right thing.
On Sun, Nov 20, 2016 at 12:45 PM Trammell Hudson hudson@trmm.net wrote:
On Sun, Nov 20, 2016 at 08:20:51PM +0000, ron minnich wrote:
[...] There's also no fundamental reason for using the name .config other than tradition. We could, for example, create build/vendor/mainboard/config and use that.
One minor concern with that placement is that I enjoy the ability to nuke a partial or corrupted builds my doing 'rm -rf coreboot/x230', so having the config file stored in a generated directory would be problematic.
I had the same thought even while writing that note. So option 2 for the config file is to create it at the top level: config.${MAINBOARD) or somewhere else. Would that work?
-
ron minnich -
Trammell Hudson