From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Hobi Date: Tue, 15 Dec 2009 10:21:02 +0100 Subject: [U-Boot] [PATCH] Makefile: fix parallel build In-Reply-To: <200912111425.09357.vapier@gentoo.org> References: <1260452467-1335-1-git-send-email-daniel.hobi@schmid-telecom.ch> <200912111425.09357.vapier@gentoo.org> Message-ID: <4B2754FE.6010906@schmid-telecom.ch> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 11.12.2009 20:25, Mike Frysinger wrote: > On Thursday 10 December 2009 08:41:07 Daniel Hobi wrote: >> During parallel build, the top Makefile spawns multiple sub-makes >> for targets in cpu/$(CPU). If cpu/$(CPU)/.depend is not present, the >> sub-makes may end up generating this file simultaneously which leads >> to corrupted content. >> >> A typical error message is: >> >> .depend:39: *** multiple target patterns. Stop. >> >> This patch serializes the creation of cpu/$(CPU)/.depend by adding >> cpu/$(CPU) to the depend target in the top Makefile. > > seems to happen in lib_$(ARCH)/ too, but in reviewing my logs from the last > few months, most parallel .depend failures have indeed been in cpu/$(CPU)/. > maybe this is just coincidence though ... perhaps the depend target should > walk all subdirs instead of a just random few ones (use LIBS). The problem with cpu/$(CPU)/ is that the top Makefile builds multiple targets within this directory in parallel - at least start.o and lib$(CPU).a. For all other directories, parallel build should work, since there is only one target per directory. Can you provide any commit ID where building lib_$(ARCH)/ failed? Thus, adding all LIBS to the depend target should not make any difference. In order to properly track such dependencies we should switch to non-recursive Makefiles (as seen in Linux) since Recursive Make [is] Considered Harmful[1]. [1] http://miller.emu.id.au/pmiller/books/rmch/ Best regards, Daniel