VIA EPIA Build Error MAX_REBOOT_CT

ron minnich rminnich at lanl.gov
Sat Apr 10 11:30:00 CEST 2004


On 9 Apr 2004, Mathieu Deschamps wrote:

> # Function to create an item like -Di586 or -DCONFIG_MAX_CPUS='1' or -Ui686
> D_item = $(if $(subst undefined,,$(origin $1)),-D$1$(if
> $($1),='$($1)',),-U$1)

youch. I had not wanted to carry this to V2, how did it get in there? 


> 
> # Compute the value of CPUFLAGS here during make's first pass.
> CPUFLAGS := $(foreach _var_,$(VARIABLES),$(call D_item,$(_var_)))

Two pass makefiles? Calls to D_item? Calls to things in a makefile? Yikes, 
why not just get rid of makefiles and generate C programs? :-)

We made a real effort with the new config tool to avoid this type of
thing. This construct is very nonportable to other make systems and it
measurably slows down the process of building. The first time I built a
bios with the new config system it took < 10 seconds. It has gotten slower
since then, not even accounting for romcc overhead.

Plus, still worse, you can't just look at a makefile and see how variables
are set. It's confusing. Another major goal of the new config tool was to
enable people to just look at Makefile.settings and know exactly what the
settings would be. This type of 'GNU make magic' removes our ability to
meet that goal. It's a de-facto second or third pass on the config tool 
which is not visible to people. 

The final problem is that this can hide errors in Config.lb files, as we
have seen. Rewriting variables in makefiles strikes me as a questionable
way to proceed.

Can someone point to a requirement that we have this in there? Why can't 
correctly structured config files remove the need for this macro?

thanks

ron





More information about the coreboot mailing list