From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19079 invoked by alias); 26 Mar 2002 04:07:39 -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 19046 invoked from network); 26 Mar 2002 04:07:37 -0000 Received: from unknown (HELO taltos.codesourcery.com) (66.92.14.122) by sources.redhat.com with SMTP; 26 Mar 2002 04:07:37 -0000 Received: from zack by taltos.codesourcery.com with local (Exim 3.35 #1 (Debian)) id 16piFD-0007vh-00; Mon, 25 Mar 2002 20:07:35 -0800 Date: Mon, 25 Mar 2002 20:07:00 -0000 To: Jim Blandy Cc: gcc@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: sharing libcpp between GDB and GCC Message-ID: <20020326040735.GM23331@codesourcery.com> References: <20020325234047.127345EA11@zwingli.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020325234047.127345EA11@zwingli.cygnus.com> User-Agent: Mutt/1.3.28i From: Zack Weinberg X-SW-Source: 2002-03/txt/msg00239.txt.bz2 On Mon, Mar 25, 2002 at 06:40:47PM -0500, Jim Blandy wrote: > > I assume there's general agreement that, if GDB and GCC are going to > share libcpp, we'll want to pull libcpp out into its own top-level > directory, with its own makefile and configure script, and move its > header files into the top-level #include directory. Is that so? Yes. > - The GCC folks could do this extraction, ensuring that GCC continues > to work. Then we can copy that directory over into GDB's > repository, and begin the libcpp/GDB integration. I like this plan, and am provisionally willing to do the work, with the warning that we're coming up on the "no more major structural changes" freeze deadline for GCC 3.2 and there are several other major structural changes I want to squeeze in (new numeric-constant parser, tm.h out of config.h, continued floating point overhaul).[1] And I'll be out of touch, and not hacking on anything, from Wednesday through the beginning of next week. It should not be terribly hard to do though. There's two hurdles. First, we have to dissociate cpplib from GCC's target configuration entirely; thanks to Eric's integrated-preprocessor patch, it's now practical to shift most of that to the C front end proper. Second, the symbol table has to be split up between the two directories while somehow maintaining its integration in the final binary. There's also a bunch of shared code, but the gcc subdir can just reference object files from the libcpp subdir. It will be another reason for bootstrap to happen at the top level; I would rather not do that myself. zw [1] If people feel that all or some of these can happen during the "smaller improvements only" phase, I'll deprioritize them a bit.