From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11894 invoked by alias); 1 Jan 2011 12:15:52 -0000 Received: (qmail 11882 invoked by uid 22791); 1 Jan 2011 12:15:49 -0000 X-SWARE-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_JMF_BL,SPF_SOFTFAIL,TW_DB X-Spam-Check-By: sourceware.org Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 01 Jan 2011 12:15:43 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LEC00I00FBK8100@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Sat, 01 Jan 2011 14:15:23 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.124.219.104]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LEC00H47FDM2GG0@a-mtaout20.012.net.il>; Sat, 01 Jan 2011 14:15:23 +0200 (IST) Date: Sat, 01 Jan 2011 12:15:00 -0000 From: Eli Zaretskii Subject: Re: [patch] make info regression on --with-system-readline In-reply-to: <20110101113955.GA26880@host1.dyn.jankratochvil.net> To: Jan Kratochvil Cc: gdb-patches@sourceware.org, tromey@redhat.com Reply-to: Eli Zaretskii Message-id: <83lj34q0mb.fsf@gnu.org> References: <20110101011319.GA27139@host1.dyn.jankratochvil.net> <8339pdq8la.fsf@gnu.org> <20110101093815.GA24535@host1.dyn.jankratochvil.net> <83y675osbp.fsf@gnu.org> <20110101113955.GA26880@host1.dyn.jankratochvil.net> X-IsSubscribed: yes 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: 2011-01/txt/msg00013.txt.bz2 > Date: Sat, 1 Jan 2011 12:39:55 +0100 > From: Jan Kratochvil > Cc: gdb-patches@sourceware.org, tromey@redhat.com > > I do not see the point playing with gdb.info build optimization. It makes the > currently situation worse only by 3.4%. Unnecessarily re-creating files is a Bad Thing, IMO, even if it isn't expensive on some platforms in some particular directory. For starters, you lose the evidence of the products' time stamps for the purposes of deducing when their prerequisites really changed. > The same optimization should be applied first to version.in / version.c as > currently whole gdb + gdbtui get relinked. I agree. > Or which operation would you like optimized? This isn't necessarily about optimization of the build time. This is about not rebuilding files that don't need to be rebuilt. We use Make to avoid that even when a complete rebuild takes only a second or less, don't we? Unnecessary rebuilds are like cancer: they spread all around, because other files may depend on those you rebuild.