From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20244 invoked by alias); 7 Aug 2008 13:47:36 -0000 Received: (qmail 20236 invoked by uid 22791); 7 Aug 2008 13:47:35 -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, 07 Aug 2008 13:47:05 +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 m77Dl3AQ028484 for ; Thu, 7 Aug 2008 09:47:03 -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 m77Dl2HN011065; Thu, 7 Aug 2008 09:47:02 -0400 Received: from opsy.redhat.com (vpn-10-34.bos.redhat.com [10.16.10.34]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m77Dl2EU012304; Thu, 7 Aug 2008 09:47:02 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 1DB17378159; Thu, 7 Aug 2008 07:47:03 -0600 (MDT) To: Ralf Wildenhues Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: automatic dependency tracking References: <20080807054840.GA26651@ins.uni-bonn.de> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Thu, 07 Aug 2008 13:47:00 -0000 In-Reply-To: <20080807054840.GA26651@ins.uni-bonn.de> (Ralf Wildenhues's message of "Thu\, 7 Aug 2008 07\:48\:41 +0200") 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-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00147.txt.bz2 >>>>> "Ralf" == Ralf Wildenhues writes: Ralf> [ChangeLog] >> (cli-decode.o, cli-dump.o, cli-interp.o, cli-logging.o, >> cli-script.o, cli-setshow.o, cli-utils.o): Likewise. Ralf> Missing cli-cmds.o. Tough crowd :) Ralf> s/by the GNUMakefile/by GNU make-specific code below/ Yeah, I thought I'd gotten that one, but I guess not. Thanks. Ralf> BSD make will complain about a rule command Ralf> $(POSTCOMPILE) Ralf> when the macro expands to empty; let's set it to '@true' instead. I don't mind either way. This must be version-specific, though, since this patch was tested on BSD, specifically FreeBSD 6.0-Release: http://sourceware.org/ml/gdb-patches/2008-07/msg00586.html What version are you using? Ralf> BSD make barfs over $< outside of inference rules. Ditto. >> # gdb/cli/ dependencies >> # >> # Need to explicitly specify the compile rule as make will do nothing >> # or try to compile the object file into the sub-directory. Ralf> Have you thought of simply compiling the object file in the sub Ralf> directory? That's not a bad option; and the makefile has already been Ralf> assuming that the compiler understands '-c -o' anyway. That comment predates my patch. I just preserved it. FWIW I did not want to change where the build puts objects; I didn't see a particular benefit to doing this. >> +@GMAKE_TRUE@$(all_object_files): | $(generated_files) Ralf> This order-only dependency requires make 3.80 or newer. Ralf> Not sure if you want to change this, but I guess the documentation Ralf> should otherwise be updated to reflect that GNU make < 3.80 can't be Ralf> used. (Or you disable GMAKE_TRUE for that...) 3.80 was released in October 2002. So, I am not really worried about this myself. I didn't see any docs to update. We could dynamically detect 3.80 by looking at .VARIABLES. (.VARIABLES was introduced in 3.80. .FEATURES wasn't introduced until 3.81, so we can't use that.) In the case where make is too old, we could emit a warning and not enable the dependency tracking, like: ifndef .VARIABLES $(warning GNU make 3.80 or later is required for automatic dependency tracking) else ... existing code endif (All protected with @GMAKE_TRUE@ of course.) What do you think of that? Of course, then we would need someone to test this with 3.79. >> +dnl For dependency tracking macros. >> +sinclude([../config/depstand.m4]) Ralf> Why sinclude? That is what the rest of the file does. In general I try to submit patches which match the prevailing style. If a cleanup is really needed, then I send that as a separate patch. Ralf> Adding the patch below on top of yours should fix all these issues. Could you just send the full, updated patch? Thanks. Tom