From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26886 invoked by alias); 26 Jun 2008 17:30:22 -0000 Received: (qmail 26878 invoked by uid 22791); 26 Jun 2008 17:30:22 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Jun 2008 17:29:22 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5QHTD5I010514; Thu, 26 Jun 2008 13:29:13 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5QHTDGv002562; Thu, 26 Jun 2008 13:29:13 -0400 Received: from opsy.redhat.com (vpn-10-86.bos.redhat.com [10.16.10.86]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5QHTBpV030464; Thu, 26 Jun 2008 13:29:12 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id EC216378296; Thu, 26 Jun 2008 11:29:10 -0600 (MDT) To: Andrew STUBBS Cc: gdb@sourceware.org Subject: Re: Automatic dependency tracking References: <200806152203.14626.pedro@codesourcery.com> <20080616012617.GA8944@caradoc.them.org> <20080625182858.GA25575@caradoc.them.org> <486365E5.50601@st.com> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Thu, 26 Jun 2008 17:30:00 -0000 In-Reply-To: <486365E5.50601@st.com> (Andrew STUBBS's message of "Thu\, 26 Jun 2008 10\:48\:21 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00280.txt.bz2 >>>>> "Andrew" == Andrew STUBBS writes: >> Daniel Jacobowitz wrote: >> Option two: we could require GNU make. GCC has done this for years, >> but binutils does not; it may be premature. >> Option three: we could manually list dependencies on generated files, >> and support dependencies on source files only on systems with GNU >> make. This effectively means GNU make is a requirement if you are >> hacking on GDB, but not to build GDB from a clean tree. Andrew> As I understand it, dependencies on generated files must always be Andrew> hard coded - otherwise the autogeneration build would fail Andrew> (potentially, with parallel make being worse), so these two options Andrew> are the same. Yeah, this is basically true -- you always have to explicitly mention the generated headers somewhere. However, with order-only dependencies, you don't actually need to maintain these by hand, in the sense of figuring out which objects depend on which generated headers. Instead you just require that the generated files all be built before anything else. Andrew> There is no need to require GNU make for build purposes. It would only Andrew> be required for dependency tracking. The configure script can be made Andrew> to disable dependency tracking on incompatible make variants. You can do this dynamically by creating a GNUMakefile in the build tree :-). Well, if you don't mind the hackiness of that. Andrew> BTW, which are the GNU make specific features in question? '-include', and probably order-only dependencies. 'ifeq' makes it a bit friendlier too, and sometimes new-style pattern rules (depending on details in the Makefile that I don't remember right now). I've appended the relevant code from libcpp's Makefile. libcpp does not use automake but does implement the dependency tracking bits. Hmm, reading it now, I see it looks like goo :) libcpp also has this: # Dependencies on generated headers have to be explicit. init.o: localedir.h But with order-only dependencies I would just write: $(all_objects): | $(generated_headers) This does the right thing. Tom # Dependency rule. COMPILE.base = $(CC) $(DEFS) $(INCLUDES) $(CPPFLAGS) $(ALL_CFLAGS) -c ifeq ($(DEPMODE),depmode=gcc3) # Note that we put the dependencies into a .Tpo file, then move them # into place if the compile succeeds. We need this because gcc does # not atomically write the dependency output file. COMPILE = $(COMPILE.base) -o $@ -MT $@ -MMD -MP -MF $(DEPDIR)/$*.Tpo POSTCOMPILE = @mv $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po else COMPILE = source='$<' object='$@' libtool=no DEPDIR=$(DEPDIR) $(DEPMODE) \ $(depcomp) $(COMPILE.base) # depcomp handles atomicity for us, so we don't need a postcompile # step. POSTCOMPILE = endif # Implicit rules and I18N .c.o: $(COMPILE) $< $(POSTCOMPILE) # Dependencies -include $(patsubst %.o, $(DEPDIR)/%.Po, $(libcpp_a_OBJS) $(makedepend_OBJS))