[U-Boot] [PATCH 18/42] Blackfin: make sure autoconf.mk is generated early enough

[Mike Frysinger]

On Wednesday 11 February 2009 16:36:37 Wolfgang Denk wrote:
> Dear Mike Frysinger,
>
> In message <200902101449.24108.vapier at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090211/ecdcfc5d/attachment.pgp