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