From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45811 invoked by alias); 27 Jan 2020 21:28:25 -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 45800 invoked by uid 89); 27 Jan 2020 21:28:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: gateway23.websitewelcome.com Received: from gateway23.websitewelcome.com (HELO gateway23.websitewelcome.com) (192.185.48.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 27 Jan 2020 21:28:23 +0000 Received: from cm12.websitewelcome.com (cm12.websitewelcome.com [100.42.49.8]) by gateway23.websitewelcome.com (Postfix) with ESMTP id C0F59718D for ; Mon, 27 Jan 2020 15:28:20 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id wBvgiJIz3vYkQwBvgi9wJK; Mon, 27 Jan 2020 15:28:20 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=HxQ5wAos+htGfT3SEACtvvAt3CeOiwzN3MLfpM4t1iI=; b=a/jqlJ/MykXKRSqLyO7JbcbbWg q7zq3+IOemfAPWP1HRkbfQv4hP2SNztzjJIwuZBv9abFZ8exINC3gnJUHNdRglO2blX25E6z+Y8sm 4DsZTAvjz/0rGh3VetsNOEPc9; Received: from 75-166-123-50.hlrn.qwest.net ([75.166.123.50]:49552 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iwBvg-001b2P-Fq; Mon, 27 Jan 2020 14:28:20 -0700 From: Tom Tromey To: Pedro Alves Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH] Move gdbserver to top level 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> Date: Tue, 28 Jan 2020 00:37:00 -0000 In-Reply-To: <01b4b5ca-a802-54b5-3135-428b7c9faa84@redhat.com> (Pedro Alves's message of "Mon, 27 Jan 2020 13:41:06 +0000") Message-ID: <87o8uo4mj0.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2020-01/txt/msg00889.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: 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. Me neither, but it seems to me that we could try to change it. My mental model is that there are certain top-level build targets (gdb, or binutils) and the rest are just dependencies of those. So, we could try not to build these dependencies unless there's a need. Pedro> People may trip on this if they try to build gdbserver for a port Pedro> for which one of those top level dirs doesn't build, like bfd. Pedro> powerpc-lynxos is I think one such case, but there are probably Pedro> others in the non-glibc space, and also off tree. FWIW there is a problem here I haven't solved yet. Right now, the top-level gdbsupport depends on BFD. This is needed for common-types.h. However, this introduces a conflict if we want to share the top-level gdbsupport with gdbserver. I'm not totally sure what to do here. Maybe we could replicate the BFD type-configury code? Like, break it out into a new .m4 file for sharing. It's been a while though, so I forget why, but I thought I had some reason this wouldn't work. 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? Makes sense, though I may take a stab at fixing the top-level instead. Pedro> However, looking at how libatomic, liboffloadmic, etc. Pedro> handle this at the top level, I see that the top level Pedro> sources a file that is also sourced by their respective Pedro> configures. I.e., the file sourced served a dual purpose. Pedro> From the top level, the file is sourced in subshell, which Pedro> avoids variable polluting the top level. This has the advantage Pedro> that you only have to write support for a port once in one file, Pedro> instead of in two places. 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? I just didn't think of it. I like your idea better, though, because it means not duplicating information. Tom