On Wednesday 11 February 2009 16:36:37 Wolfgang Denk wrote: > Dear Mike Frysinger, > > In message <200902101449.24108.vap...@gentoo.org> you wrote: > > > > > > + @$(MAKE) -s -B $(obj)include/autoconf.mk > > > > > > + @$(MAKE) -s -B $(obj)include/autoconf.mk > > > > > > > > > > Do you really mean to do this twice? > > > > > > > > unfortunately, yes. since some settings in the board config are > > > > turned into compiler flags and those compiler flags can in turn > > > > affect the board config, we need to do it twice. first is to make > > > > sure the proper cpu flags are propagated into the toplevel build env > > > > while the second is to make sure the autoconf.mk fully reflects the > > > > board config. > > > > > > Sounds like a design problem to me. > > > > not really. the point is to avoid duplication and considering the method > > to attain that, sounds pretty good to me. > > Well, no othe rarchitecture seems to need that, and it looks very > strange. I guess 4 out of 5 persons who will see this are tempted to > "clean this up".
that's why i said i would add comments. they're in there now and anyone touching code that doesnt belong to them while ignoring the comments shouldnt be doing clean up work in the first place. > > > That would be the minimum, but given the fact that the top level > > > Makefile already includes rules to build autoconf.mk I really wonder > > > if we must do this so often, and if so, then why this is only the > > > case for blackfin. > > > > the top level Makefile includes rules to build it, but it doesnt > > re-source it once it's been generated. so anything in the top level > > cannot use things from autoconf.mk (like $(arch)_config.mk). > > To me it seems as if you were rebuilding it twice without re-sourcing > it inbetween, too. > > And you fail to explain why BF needs this, while all other > architectures don't. i explained it already when Ben asked. the processor variant is selected in the board config and the board config (and shared settings) can change based on that selection. and the top level build flags use that processor selection. first one is to make sure the cpu settings make it from the board config into the environment while the second is to make sure the board config has been fully processed by the proper cpu selection. also, other people dont seem to have a problem sprinkling duplication over the place until things work. i do. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
