From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58699 invoked by alias); 7 Feb 2020 16:06:17 -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 58686 invoked by uid 89); 7 Feb 2020 16:06:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=FOSDEM, fosdem, opportunity, day X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Feb 2020 16:06:15 +0000 Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 0653F1E56E; Fri, 7 Feb 2020 11:06:12 -0500 (EST) Subject: Re: [PATCH] Move gdbserver to top level To: Tom Tromey Cc: Pedro Alves , gdb-patches@sourceware.org References: <87d0bf45up.fsf@tromey.com> <7ceebbb7-b2f7-3d4a-1d8a-f31310badbe8@redhat.com> <874kwk8nz9.fsf@tromey.com> <171a3144-af37-1c29-a2a4-c4cd7eaa14c0@redhat.com> <87r1zm6x8s.fsf@tromey.com> <01b4b5ca-a802-54b5-3135-428b7c9faa84@redhat.com> <87o8uo4mj0.fsf@tromey.com> <87blqfn0d6.fsf@tromey.com> From: Simon Marchi Message-ID: <6d702998-eed9-13d0-56c2-ebdeeb8088b2@simark.ca> Date: Fri, 07 Feb 2020 16:06:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <87blqfn0d6.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-02/txt/msg00175.txt.bz2 On 2020-02-03 4:34 p.m., Tom Tromey wrote: > Pedro> I guess it's the intended design for top level to build readline, bfd, > Pedro> etc. by default even if no application is being built that depends > Pedro> on them. I don't know. > > [...] > > Pedro> So I'm thinking that it might be better to document "make > Pedro> all-gdbserver" instead of the --disable approach. Or at least, > Pedro> mention it as alternative. WDYT? > > Tom> Makes sense, though I may take a stab at fixing the top-level instead. > > We talked about this at FOSDEM and Pedro convinced me to just go ahead > with the documentation change and the move, and consider changing the > top-level configury later. > > Pedro> The equivalent for gdbserver would be the patch below, > Pedro> which seems to work well. Was there a reason you didn't follow > Pedro> libatomic's (etc.) model? > > Tom> I just didn't think of it. I like your idea better, though, because it > Tom> means not duplicating information. > > I've pulled this patch into mine. > > I'm going to push it tomorrow or the day after, unless there's some > objection. I have no objection. I think for a big change like that we have to expect we'll get some things wrong that we'll need to fix afterwards, no big deal. It was suggested (on IRC, maybe on the mailing list too) that since we have moved the gdbsupport directory, and are moving the gdbserver directory, we should take the opportunity to rename these source files to .cc/.cxx/.cpp. I also have no objection to that. Simon