From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11899 invoked by alias); 8 Mar 2004 19:26:17 -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 11803 invoked from network); 8 Mar 2004 19:26:14 -0000 Received: from unknown (HELO yosemite.airs.com) (209.128.65.135) by sources.redhat.com with SMTP; 8 Mar 2004 19:26:14 -0000 Received: (qmail 6518 invoked by uid 10); 8 Mar 2004 19:26:13 -0000 Received: (qmail 2366 invoked by uid 500); 8 Mar 2004 19:26:11 -0000 From: Ian Lance Taylor To: Andrew Cagney 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> <404CC47A.4090207@gnu.org> Date: Fri, 19 Mar 2004 00:09:00 -0000 In-Reply-To: <404CC47A.4090207@gnu.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-03/txt/msg00173.txt.bz2 Message-ID: <20040319000900.Vxo_bxUwiSv41tWmhI6Ap-Ot9j2scwga3HdpHfg2eWE@z> Andrew Cagney writes: > > '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. I would say that it depends on the speed cost. Dependencies rarely change. In my opinion, it's not worth a measurable slowdown to configure--a price paid by everybody who builds from source--to handle them correctly. If your code runs quickly, and correctly handles things like the way mips-tdep.o depends upon include/elf/reloc-macros.h (something which the current gdb Makefile does not appear to get right), then I'm sure your plan is fine. > 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. The only people who need to update dependencies lists for the binutils are people doing development on the binutils. For those people, I do not consider gcc to be a specialized tool. (I do consider automake to be a specialized tool.) The set of people who do serious binutils work and who do not have access to gcc on any platform is a null set. And of course the dependencies are written so that they are very simple to update by hand, for quick hacks by developers. > 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. The binutils use none of the above. Maintainers are supposed to update the dependencies when they change them. We periodically update the dependencies anyhow, to catch anything which wasn't handled earlier. And we update the dependencies at release time as well. Ian