From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8700 invoked by alias); 28 May 2003 22:51:13 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8611 invoked from network); 28 May 2003 22:51:12 -0000 Received: from unknown (HELO smtp-send.myrealbox.com) (192.108.102.143) by sources.redhat.com with SMTP; 28 May 2003 22:51:12 -0000 Received: from myrealbox.com nwourms@smtp-send.myrealbox.com [130.127.122.186] by smtp-send.myrealbox.com with NetMail SMTP Agent $Revision: 3.34 $ on Novell NetWare via secured & encrypted transport (TLS); Wed, 28 May 2003 15:51:08 -0700 Message-ID: <3ED53CC0.9040305@myrealbox.com> Date: Wed, 28 May 2003 22:51:00 -0000 From: Nicholas Wourms User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb , binutils Subject: Re: parallel builds failing in bfd References: <20030528220621.GA24942@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00378.txt.bz2 Daniel Jacobowitz wrote: > On Wed, May 28, 2003 at 03:01:48PM -0700, David Carlton wrote: > >>Every once in a while, when I do a parallel build from the top level, >>I get a failure that stems from bfd.h being built incorrectly. Do >>other people run into this problem? I'm not at all familiar with >>bfd's Makefile.in, so I don't know offhand what might be causing this >>problem. > > > It's an autoconf 2.13 bug unfortunately. It will be fixed after the > 2.5x transition, which is starting to gain a little momentum now. > BTW, are there any plans to transition to Automake-1.7.X & Libtool-1.5.X, now that they have stabilized? It sure would be nice to finally have a consolidated, streamlined build without all this leftover Cygnus tree building crap. Yes, I dare say to ditch the current cruft which is polluting Makefile.in's. There should be no reason why the entire configury can't happen in one shot. Yes, I am aware that it must support mixed trees, which is why one would put conditional guards around subproject macros, running them only iff said subproject directory is present in the source tree. It would save time and, for some, resources [since repeatedly calling the Autom4te/Automake perl functions (when checking for autoheader, etc.) tends to hog resources]. Not to mention the fact that {in-tree,parallel,distcc} building is *much* easier to implement and less prone to break with the latest versions of these tools. The biggest advantage, by far, would be to bring subproject Makefile templates inline with some sort of general standard, which is generally enforced by the current Automake/Autoconf macros (whereas previous versions of autoconf/automake were rather lax). Just my $0.02... Feel free to disagree :-) Cheers, Nicholas