From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8206 invoked by alias); 2 Nov 2011 17:39:33 -0000 Received: (qmail 7955 invoked by uid 22791); 2 Nov 2011 17:39:31 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta06.westchester.pa.mail.comcast.net (HELO qmta06.westchester.pa.mail.comcast.net) (76.96.62.56) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Nov 2011 17:39:17 +0000 Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta06.westchester.pa.mail.comcast.net with comcast id sHeR1h0041c6gX856HfJ75; Wed, 02 Nov 2011 17:39:18 +0000 Received: from up.mrs.kithrup.com ([24.4.193.8]) by omta23.westchester.pa.mail.comcast.net with comcast id sHfG1h01m0BKwT43jHfH3N; Wed, 02 Nov 2011 17:39:17 +0000 Subject: Re: building binutils from same directory as gcc Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mike Stump In-Reply-To: <4EB17B28.8060704@redhat.com> Date: Wed, 02 Nov 2011 17:45:00 -0000 Cc: gcc-patches@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EAFD7AC.4000806@redhat.com> <4EB11071.5050203@redhat.com> <4EB17B28.8060704@redhat.com> To: Andrew Haley X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg00186.txt.bz2 On Nov 2, 2011, at 10:17 AM, Andrew Haley wrote: > Sure, but that doesn't answer the question, which was "is there ever > any advantage to building in-srcdir?" The answer "Yes: one can build > in srcdir" doesn't quite do it! Well, unstated in that is that one doesn't have to manually create an objec= t directory. Also, unstated in that, is that to build a random package, on= e doesn't have to read the documentation to configure and build it, they ca= n just build it. and it will just work. These are the advantages. It used to be the case, a long time ago, that building software was a rando= m hodge-podge of weird random commands, the situation has been improving ov= er the years to standardize on a few small incantations that work. The con= figure && make && make install, was the command standardized on, right afte= r make && make install. It is like explaining the advantage of a red stop light being red. It is r= ed, because all stop lights are red. This is nicely circular. The reason = _why_ is have a standard, isn't just to make the light red, it is so that a= ll users of all stop lights expect it to be red, and if it weren't bad thin= gs would happen. We make ./configure && make && make install work, because our users expect = it to work, and there is no reason to break that assumption.