From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32012 invoked by alias); 8 Mar 2004 19:07:40 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 32005 invoked from network); 8 Mar 2004 19:07:38 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 8 Mar 2004 19:07:38 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id BD27F2B92; Mon, 8 Mar 2004 14:07:38 -0500 (EST) Message-ID: <404CC47A.4090207@gnu.org> Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Ian Lance Taylor Cc: Daniel Jacobowitz , Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Generate makefile dependencies References: <404BBFD6.1060702@gnu.org> <6137-Mon08Mar2004080725+0200-eliz@elta.co.il> <404C9E34.4010809@gnu.org> <20040308172924.GA20940@nevyn.them.org> <404CB609.4070609@gnu.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00171.txt.bz2 > Andrew Cagney writes: > > >>>> > BTW, your comment about running automake to update deps in BFD is >>>> > actually incorrect. You run 'make dep-am', which IIRC seds Makefile.am >>>> > and maye regenerates Makefile.in; the dependencies aren't managed by >>>> > automake. Recent versions of automake do have top-notch dependency >>>> > support though. >> >>> >>> It appears to eventually run "gcc -MM" ... :-( > > > Assuming you are talking about 'make dep-am' in the binutils, that is > irrelevant. > 'make dep-am' is run by a binutils maintainer, not by an ordinary > user. It does happen to run gcc -MM, so the binutils maintainer is > required to have gcc installed. However, the result is the correct > dependencies for any compiler, and those dependencies are then present > in the Makefile for any user, regardless of what compiler they use. Right, which was part of my motivation for proposing that it be done this way: > The attached, er, hack, modifies configure.in so that all the Makefile dependencies are generated during configure time: > > defs_h = ... > foo.o: foo.c $(defs_h) > > It exploits the fact that GDB's code base is very consistent in its use of "foo.h" vs -- the former is assumed to be local, the latter in a system library. > > Instead of having to to edit Makefile.in, or as with binutils, run automake, you just enter: > ./config.cache --recheck > > Thoughts? Wonder how portable my SED is. While Daniel's pointed out that for binutils "make dep-am" (and hence gcc -MM) and not "automake" are used, the problem still stands - correct dependency lists are only available if a specialized set of tools are installed. For what its worth, I know of three ways to maintain a dependency list: - update at compile time - update at configure time - update at release time For someone grabbing random sources, the first is most likely correct, the last is most likley out-of-date. The middle is a compromise, at least correct at the start of each build. Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32012 invoked by alias); 8 Mar 2004 19:07:40 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 32005 invoked from network); 8 Mar 2004 19:07:38 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 8 Mar 2004 19:07:38 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id BD27F2B92; Mon, 8 Mar 2004 14:07:38 -0500 (EST) Message-ID: <404CC47A.4090207@gnu.org> Date: Mon, 08 Mar 2004 19:07:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Ian Lance Taylor Cc: Daniel Jacobowitz , Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Generate makefile dependencies References: <404BBFD6.1060702@gnu.org> <6137-Mon08Mar2004080725+0200-eliz@elta.co.il> <404C9E34.4010809@gnu.org> <20040308172924.GA20940@nevyn.them.org> <404CB609.4070609@gnu.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00171.txt Message-ID: <20040308190700.suNLBcuHvrMp4N2BTRqYPotJQXbpo8SjSctDBvJ8rtU@z> > Andrew Cagney writes: > > >>>> > BTW, your comment about running automake to update deps in BFD is >>>> > actually incorrect. You run 'make dep-am', which IIRC seds Makefile.am >>>> > and maye regenerates Makefile.in; the dependencies aren't managed by >>>> > automake. Recent versions of automake do have top-notch dependency >>>> > support though. >> >>> >>> It appears to eventually run "gcc -MM" ... :-( > > > Assuming you are talking about 'make dep-am' in the binutils, that is > irrelevant. > 'make dep-am' is run by a binutils maintainer, not by an ordinary > user. It does happen to run gcc -MM, so the binutils maintainer is > required to have gcc installed. However, the result is the correct > dependencies for any compiler, and those dependencies are then present > in the Makefile for any user, regardless of what compiler they use. Right, which was part of my motivation for proposing that it be done this way: > The attached, er, hack, modifies configure.in so that all the Makefile dependencies are generated during configure time: > > defs_h = ... > foo.o: foo.c $(defs_h) > > It exploits the fact that GDB's code base is very consistent in its use of "foo.h" vs -- the former is assumed to be local, the latter in a system library. > > Instead of having to to edit Makefile.in, or as with binutils, run automake, you just enter: > ./config.cache --recheck > > Thoughts? Wonder how portable my SED is. While Daniel's pointed out that for binutils "make dep-am" (and hence gcc -MM) and not "automake" are used, the problem still stands - correct dependency lists are only available if a specialized set of tools are installed. For what its worth, I know of three ways to maintain a dependency list: - update at compile time - update at configure time - update at release time For someone grabbing random sources, the first is most likely correct, the last is most likley out-of-date. The middle is a compromise, at least correct at the start of each build. Andrew