Am 09.02.2010 08:45, schrieb Peter Stuge:
repository service wrote:
fix further build.h dependencies that were undetected before we enabled it on our parallel build server ;-)
..
+++ trunk/src/mainboard/amd/db800/Makefile.inc Sun Feb 7 23:56:06 2010 (r5091) @@ -21,7 +21,7 @@
ifdef POST_EVALUATION
-$(obj)/mainboard/$(MAINBOARDDIR)/auto.inc: $(src)/mainboard/$(MAINBOARDDIR)/cache_as_ram_auto.c +$(obj)/mainboard/$(MAINBOARDDIR)/auto.inc: $(src)/mainboard/$(MAINBOARDDIR)/cache_as_ram_auto.c $(obj)/build.h
Please talk a little more about this build.h again? I think it's a pretty unclean thing to deal with in mainboard directories.
I think we can get rid of that rule in mainboard directories altogether. Would that fix it?
Does it affect only romcc boards or only car boards or both?
All boards.
How can we get rid of build.h completely? (Yes, I know I asked before.)
What happens in the build: kconfig generates config.h, which carries all the CONFIG_* definitions. The build.h file is created by make rules and contains a couple more definitions, mostly those with COREBOOT_*, and an include of config.h.
There's no simple way to force make to wait for this file to be created except by telling it that _all_ files depend on it. First, it failed on some random coreboot object file. When we made all of those depend on build.h, make cleverly decided that these auto.incs above are "safe" to do parallely to build.h
Another approach to solve this conflict (apart from making everything depend on build.h) would be to generate build.h on config time. Not sure if that leads to desired results.
Patrick