From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Tue, 10 Feb 2009 14:49:23 -0500 Subject: [U-Boot] [PATCH 18/42] Blackfin: make sure autoconf.mk is generated early enough In-Reply-To: <20090210194220.E739A832E893@gemini.denx.de> References: <1234246880-32438-1-git-send-email-vapier@gentoo.org> <200902101357.29507.vapier@gentoo.org> <20090210194220.E739A832E893@gemini.denx.de> Message-ID: <200902101449.24108.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tuesday 10 February 2009 14:42:20 Wolfgang Denk wrote: > Dear Mike Frysinger, > > In message <200902101357.29507.vapier@gentoo.org> you wrote: > > > > $(BFIN_BOARDS:%=%_config) : unconfig > > > > @$(MKCONFIG) $(@:_config=) blackfin blackfin $(@:_config=) > > > > + @$(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. > > i guess i could add a one line comment above each one giving hints about > > why each is needed ... > > 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). -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/20090210/e9b4a053/attachment.pgp