From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26592 invoked by alias); 18 Aug 2009 19:14:17 -0000 Received: (qmail 26572 invoked by uid 22791); 18 Aug 2009 19:14:16 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.gmx.net (HELO mail.gmx.net) (213.165.64.20) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Tue, 18 Aug 2009 19:14:08 +0000 Received: (qmail invoked by alias); 18 Aug 2009 19:14:05 -0000 Received: from xdsl-87-78-235-133.netcologne.de (EHLO localhost.localdomain) [87.78.235.133] by mail.gmx.net (mp026) with SMTP; 18 Aug 2009 21:14:05 +0200 Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1MdU8C-00084J-FX; Tue, 18 Aug 2009 21:14:04 +0200 Date: Tue, 18 Aug 2009 19:36:00 -0000 From: Ralf Wildenhues To: "Joseph S. Myers" , Dave Korn Cc: binutils@sourceware.org, gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com Subject: Re: [PATCH 4/N] The big bump Message-ID: <20090818191404.GB30961@gmx.de> Mail-Followup-To: Ralf Wildenhues , "Joseph S. Myers" , Dave Korn , binutils@sourceware.org, gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A86E723.3000602@gmail.com> User-Agent: Mutt/1.5.20 (2009-08-09) X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2009-08/txt/msg00343.txt.bz2 * Joseph S. Myers wrote on Sat, Aug 15, 2009 at 06:26:38PM CEST: > On Sat, 15 Aug 2009, Dave Korn wrote: > > > Looking at the toplevel of/src, there are no changes to blt/, cgen/, cpu/, > > dejagnu/, elfcpp/, expat/, expect/, itcl/, iwidgets/, libgloss/, libgui/, > > mmalloc/, newlib/, rda/, sid/, tcl/, texinfo/, tix/, tk/, utils/ and winsup/. > > Are these all unaffected or are some of them liable to need updates too? > > Some of these do not exist on HEAD; they only have files in the Attic. [...] > I think cgen/ libgloss/ libgui/ newlib/ rda/ sid/ utils/ winsup/ actually > live in the src repository as their main home. Plus sim/, as Tom noted. * Dave Korn wrote on Sat, Aug 15, 2009 at 06:49:39PM CEST: > > Well, the winsup/ directory is pretty heavily used, winsup == cygwin + > mingw! I can help with the testing if you can help with the patching; winsup > depends on newlib, so I can test those together for you. I think Joseph's > cut-down list looks about right for the rest. Thanks guys. Does anyone have an up to date git clone of the full src tree? If not, are there any volunteers to set one up, or can I bribe one? I have ventured a wee bit into building the whole tree, GNU/Linux and Cygwin native builds. Observing the autotools version used right now: - sid/component/tcl was configured with Autoconf 2.61, - parts of winsup with Autoconf 2.63, - parts of itcl with 2.61, - parts of libgloss with 2.61, - parts of tk and parts of tcl with 2.60a, Automake 1.9.3 has seen usage, 1.9.5 and 1.10 (sid), 1.4 and 1.4-p5 (rda, libgloss, utils are all candidates). - libgloss/testsuite and ../libgloss.all has files named configure.in which are not meant to be input files to autoconf (and are probably dead for 12 years?). Oberving build times: Cygwin takes several hours to build. A conservative estimate is that I will need around 10 or more builds to get the current tree to run without and with maintainer-mode enabled, then update autotools, then retry the same again, plus bugfixing on the way, then sort patches in logical order and retry patches in that order. (This is how I did the rest of the tree, during the last months; if you like, I can post a detailed recipe). So, I expect this to take a few weekends, even without more surprises. In light of the expected Stage 1 end for GCC, allow me to ask again: May I proceed in updating the tree to 2.64/1.11 before getting the rest of the tree (that already has out-of-sync autotools) back into sync? This patch series is almost ready to go otherwise (expect to be able to commit this weekend), and it'd be sad to see it hostage of the lesser tightly maintained part of the tree. (Not to speak of the extra work required to keep the current patch series in sync with other changes while it is still pending.) Thanks, Ralf