From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8472 invoked by alias); 9 May 2003 18:41:59 -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 8336 invoked from network); 9 May 2003 18:41:57 -0000 Received: from unknown (HELO delorie.com) (207.22.48.162) by sources.redhat.com with SMTP; 9 May 2003 18:41:57 -0000 Received: from envy.delorie.com (envy.delorie.com [207.22.48.171]) by delorie.com (8.11.6/8.9.1) with ESMTP id h49Ifqq28742; Fri, 9 May 2003 14:41:52 -0400 Received: from envy.delorie.com (localhost [127.0.0.1]) by envy.delorie.com (8.12.8/8.12.8) with ESMTP id h49IfpJL016611; Fri, 9 May 2003 14:41:51 -0400 Received: (from dj@localhost) by envy.delorie.com (8.12.8/8.12.8/Submit) id h49IfpsU016607; Fri, 9 May 2003 14:41:51 -0400 Date: Fri, 09 May 2003 18:41:00 -0000 Message-Id: <200305091841.h49IfpsU016607@envy.delorie.com> From: DJ Delorie To: phil@jaj.com CC: dhazeghi@yahoo.com, gcc@gcc.gnu.org, binutils@sources.redhat.com, gdb@sources.redhat.com In-reply-to: <20030509181925.GD1188@disaster.jaj.com> (message from Phil Edwards on Fri, 9 May 2003 14:19:25 -0400) Subject: Re: srcdir == objdir build issues [SC take note] References: <20EC888E-81F7-11D7-9B47-000393681B36@yahoo.com> <200305091755.h49Htqc21246@greed.delorie.com> <20030509181925.GD1188@disaster.jaj.com> X-SW-Source: 2003-05/txt/msg00146.txt.bz2 > There's no reason to make it gratuitously fail. I implemented a > patch that would solve both problems: configury only has to deal > with out-srcdir builds, plus the users can do "./configure; make" > with no surprises. Given how much trouble I've had keeping ./configure working, I think any new twists will end up with the same fate. At this point, I'd accept your solution if I thought it would help, but I think it would end up the same as what we have now - unsupportable. The problem is getting the regular gcc developers to test setups other than the common one. Either they're going to test them, or they aren't. If they're going to test them, we can continue supporting ./configure the "natural" way. If they're not going to test them, let's not fool ourselves into thinking we can support it. If the solution is to build in a separate directory, let's just tell the user that, require it, and get rid of all the cruft that's been added to support anything else. Just getting rid of the cruft will help with maintenance costs too. At least then the supported setups will be well tested and maintained.