[coreboot] [commit] r5091 - in trunk/src/mainboard: amd/db800 amd/norwich digitallogic/msm800sev iei/pcisa-lx-800-r10 lippert/roadrunner-lx lippert/spacerunner-lx

Patrick Georgi patrick at georgi-clan.de
Tue Feb 9 08:58:34 CET 2010

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 @@
>> -$(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.


More information about the coreboot mailing list