From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32206 invoked by alias); 6 Aug 2013 08:48:20 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 32188 invoked by uid 89); 6 Aug 2013 08:48:20 -0000 X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 06 Aug 2013 08:48:19 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r768mBvr022167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Aug 2013 04:48:11 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r768m9Il028601; Tue, 6 Aug 2013 04:48:09 -0400 Message-ID: <5200B848.40500@redhat.com> Date: Tue, 06 Aug 2013 08:48:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mark Kettenis CC: tromey@redhat.com, lgustavo@codesourcery.com, gdb-patches@sourceware.org Subject: Re: [PATCH] Refactor common/target-common into meaningful bits References: <51FA9649.5060008@codesourcery.com> <87vc3pfghs.fsf@fleche.redhat.com> <51FAA061.4050005@codesourcery.com> <51FB7BFB.90100@redhat.com> <87txj7byz7.fsf@fleche.redhat.com> <51FF81E6.7050006@redhat.com> <87bo5c7y0x.fsf@fleche.redhat.com> <201308051920.r75JKhN7009020@glazunov.sibelius.xs4all.nl> In-Reply-To: <201308051920.r75JKhN7009020@glazunov.sibelius.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-08/txt/msg00166.txt.bz2 On 08/05/2013 08:20 PM, Mark Kettenis wrote: >> From: Tom Tromey >> Date: Mon, 05 Aug 2013 13:11:58 -0600 >> >>>>>>> "Pedro" == Pedro Alves writes: >> >> Pedro> I've read your email several times over, and I sense that we're >> Pedro> talking past each other. >> >> Yeah. And thanks for your follow-up, I think it is clarifying. >> >> Pedro> Yep. So, if we move the classic "target" bits to a "target/" >> Pedro> module directory, and put the native bits in their own dir, we >> Pedro> have: >> >> Pedro> target/resume.h >> Pedro> target/waitstatus.[c|h] >> Pedro> target/wait.h >> Pedro> nat/i386-nat.c >> Pedro> nat/linux-nat.c >> Pedro> nat/linux-ptrace.c >> Pedro> nat/linux-waitpid.c >> Pedro> etc. >> >> Pedro> Is this what you're thinking of? _This_, I'm fine with. >> >> Yeah, this is what I think we ought to do. >> >> Pedro> It's actually very similar to something else I suggested on IRC, >> Pedro> but forgot to put in email form: "IMO, the interfaces themselves >> Pedro> would be in an include dir. e.g., >> Pedro> gdb/include/target-waitstatus.h or some such, and then we'd have >> Pedro> gdb/nat/linux-nat.c, etc." >> >> I'm usually against include dirs, but if they are near enough to the >> implementation it is ok by me. My issue with them is mainly >> forgettability -- like, I never, ever remember to look for things in >> src/include/gdb; and then directories like this tend to become forgotten >> graveyards. Agreed. grep-friendliness is the antithesis of scattering things around in lots of out of sight subdirs. But note I was suggesting a new gdb/include/, not the existing src/include/gdb. Anyway, let's leave this idea out for now. > Yea, we shouldn't put anything in src/include/gdb unless it is > absolutely necessary. That pretty much translates into "unless sim > needs it". *nod* -- Pedro Alves