From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11515 invoked by alias); 20 Dec 2002 00:24:36 -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 11502 invoked from network); 20 Dec 2002 00:24:34 -0000 Received: from unknown (HELO mailout5-0.nyroc.rr.com) (24.92.226.169) by 209.249.29.67 with SMTP; 20 Dec 2002 00:24:34 -0000 Received: from doctormoo (syr-24-24-16-193.twcny.rr.com [24.24.16.193]) by mailout5-0.nyroc.rr.com (8.11.6/RoadRunner 1.20) with ESMTP id gBK0OJF15806 for ; Thu, 19 Dec 2002 19:24:19 -0500 (EST) Received: from neroden by doctormoo with local (Exim 3.36 #1 (Debian)) id 18PAwc-0000PC-00 for ; Thu, 19 Dec 2002 19:23:14 -0500 Date: Thu, 19 Dec 2002 16:24:00 -0000 To: gdb@sources.redhat.com Subject: Re: "cd dir && $(MAKE)", not "cd dir; $(MAKE)" Message-ID: <20021220002314.GA15166@doctormoo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i From: Nathanael Nerode X-SW-Source: 2002-12/txt/msg00296.txt.bz2 Regarding the subject line, please do it; I just hadn't gotten around to it for all targets. Doug Evans said: >I've been playing around trying to get things to build. >Since gcc is in another tree and yet requires installed binutils (*1), >I let the make run long enough to build binutils,gas,ld, and >then did a "make install". That's how this happened. >[Actually that's not entirely true. I'm summarizing, but >I'm guessing the effect is the same.] Not necessarily. :-/ But interrupting 'make' in the middle can give all manner of screwy results now; don't rely on it. If you want to build just binutils, gas, and ld, and then install them, I strongly suggest doing the following: make all-binutils all-gas all-ld make install-binutils install-gas install-ld This should do exactly what it says. If you had other directories in the same source tree (such as etc) when you were configuring, then they may get automagically configured and built. If you deleted the directories you didn't want *before* running toplevel configure, you should be OK. We're also planning on a way to specify to top level configure "Just don't configure this directory" -- probably something like --without- -- it should be easy but it hasn't actually happened yet. >Has anyone gotten a "one-tree" tree to build yet under the >new configure regime? Yep, I have. I wouldn't have committed it otherwise. And obviously I missed a lot of subtle points, but I've been fixing them as they appear. You should be able to build the gcc tree, the complete src tree, or the merged gcc-src tree. You should also be able to build the trees corresponding to a gdb distribution, an insight distribution, a binutils distribution, a newlib distribution, or any of the gcc 'sub-distributions'. I haven't tested all of these at once (since it's a pain in the neck), but I have tested each of them at one time or another during the process; and the code is theoretically correct. If a problem is encountered in any one of these, I will strive to fix it (and it will probably be pretty straightforward, unless it's gdb vs. insight, which is a bit messier). --Nathanael