From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22207 invoked by alias); 1 Sep 2009 21:00:52 -0000 Received: (qmail 22194 invoked by uid 22791); 1 Sep 2009 21:00:51 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_20,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.gmx.net (HELO mail.gmx.net) (213.165.64.20) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Tue, 01 Sep 2009 21:00:46 +0000 Received: (qmail invoked by alias); 01 Sep 2009 21:00:42 -0000 Received: from xdsl-87-79-128-232.netcologne.de (EHLO localhost.localdomain) [87.79.128.232] by mail.gmx.net (mp066) with SMTP; 01 Sep 2009 23:00:42 +0200 Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1MiaT4-0003JB-Dp; Tue, 01 Sep 2009 23:00:42 +0200 Date: Tue, 01 Sep 2009 21:00:00 -0000 From: Ralf Wildenhues To: Dave Korn Cc: Jie Zhang , binutils@sourceware.org Subject: Re: Parallel build error for Blackfin target Message-ID: <20090901210042.GB11144@gmx.de> References: <4A9CC410.7060301@analog.com> <4A9CCC56.9090008@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A9CCC56.9090008@gmail.com> User-Agent: Mutt/1.5.20 (2009-08-09) X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00042.txt.bz2 * Dave Korn wrote on Tue, Sep 01, 2009 at 09:25:10AM CEST: > Jie Zhang wrote: > > bfin-lex.o: bfin-lex.c bfin-parse.h $(srcdir)/config/bfin-defs.h > > $(COMPILE) -c $< $(NO_WERROR) > > > > Now > > > > bfin-lex.o: bfin-lex.c [...] > > Should I add back "bfin-parse.h $(srcdir)/config/bfin-defs.h" as the > > dependency of bfin-lex.o? > > Perhaps $(srcdir)/config/bfin-defs.h should be added as a preqrequisite of > bfin-parse.c (and hence implicitly of bfin-parse.h). > > Really the whole thing needs some kind of sentinel or stamp wrapped around > it(*); The .c file or the .h file can be the sentinel, though. The only problem then is if their time stamp order is not the way we'd expect. > what we've got here is the typical "make doesn't understand when a > single rule updates more than one target at once" situation. Running the rule > for bfin-parse.c actually also creates bfin-parse.h, which is what > necessitates the not-really-true-actually dependency of bfin-parse.h on > bfin-parse.c and the corresponding "@true" build rule. See also Paul D. > Smith's Rules of Makefiles; this violates #2. Yes, but we violate rule #1 by using non-GNU make, too. ;-) The Automake manual has a node 'Multiple Outputs' that describes portable (i.e., also to non-GNU make) approaches to the issue. > (*) - or perhaps to be converted to a multiple-output pattern rule, the other > way to resolve this kind of situation and the one place where make does > understand it might generate multiple outputs from a single rule. Pattern rules are GNU make-specific. AFAICS the current binutils-gdb tree builds fine with FreeBSD make, for example (tried that out a couple of days ago). I'm wondering whether we should just bite the bullet and let automake treat the yacc and lex files completely. That would require another make indirection (implied through BUILT_SOURCES) and convenience archives for the per-target flags, but it should avoid us needing to think about this further. (I haven't tested such a patch yet, though.) Cheers, Ralf