From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12916 invoked by alias); 10 May 2003 04:56:15 -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 12788 invoked from network); 10 May 2003 04:56:14 -0000 Received: from unknown (63.201.54.26) by sources.redhat.com with QMTP; 10 May 2003 04:56:14 -0000 Received: (qmail 16782 invoked by uid 10); 10 May 2003 04:56:14 -0000 Received: (qmail 23824 invoked by uid 500); 10 May 2003 04:56:07 -0000 Mail-Followup-To: bkoz@redhat.com, gcc@gcc.gnu.org, binutils@sources.redhat.com, gdb@sources.redhat.com, dj@delorie.com To: DJ Delorie Cc: bkoz@redhat.com, gcc@gcc.gnu.org, binutils@sources.redhat.com, gdb@sources.redhat.com Subject: Re: srcdir == objdir build issues [SC take note] References: <20030509201035.51143c7d.bkoz@redhat.com> <200305100140.h4A1eKqB022183@envy.delorie.com> From: Ian Lance Taylor Date: Sat, 10 May 2003 04:56:00 -0000 In-Reply-To: <200305100140.h4A1eKqB022183@envy.delorie.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg00177.txt.bz2 DJ Delorie writes: > > Did anybody not like this approach? I was surprised this did not go in. > > I had misgivings about a setup where you tell the software to do one > thing, and it does something completely different. It also added a > maintenance headache for the "synthetic" top-level Makefile, since > every target in the real Makefile would have to be replicated (and > maintained - for ever). It's far easier to just tell the user to > build elsewhere. For what it's worth, I agree. Personally, I think the only reasonable choices are: 1) Have ./configure work in the expected and normal fashion; that is, put .o files next to the .c files, and only create new subdirectories for unusual cases like multilib. This obviously requires regular testing, which is simple, and a commitment to keep it working, which is harder but should be doable. or 2) Have ./configure simply fail with an error message directing the user to acquire GNU make and build in a different directory. I think that having ./configure do something else is an increase in complexity for no clear benefit. I believe the point of having ./configure work is to make gcc behave like most other programs. That is, I think the goal ``./configure must work'' is incomplete. The right goal is ``./configure must behave as expected.'' Either implement that goal, or have it fail in an obvious and straightforward fashion. Ian